1 



HEWLETT-PACKARD 

JOURNAL 



October 1992 




That HEWLETT 
PACKARD 



HEWLETT-PACKARD 

JOURNAL Oclober 1992 Volume 43 • Number 5 



Articles 



9 



The HP Network Advisor: A Portable Test Tool for Protocol Analysis, by Edmund G. Moore 
Network Advisor Product Enhancement Philosophy 



Embedding Artificial Intelligence in a LAN Test Instrument, by Scot! Godlew, Rod Unverrich, and 
Stephen Witt 

^2 The User Interface for the HP 4980 Network Advisor Protocol Analyzer, by Thomas A. Doumas 
24 Object-Oriented Design and Smalltalk 
2 ^ The Forth Interpreter 

| The Network Advisor Analysis and Real-Time Environment, by Sunil Bhal 

^ ^ Network Advisor Protocol Analysis: Decodes, by Rona J. Pruler 

Mechanical Design of the HP 4980 Network Advisor, by Kenneth R. Krebs 

/| Q The Microwave Transition Analyzer: A New Instrument Architecture for Component and Signal 
Analysis, by David J. Ballo and John A. Wendler 

Frequency Translation as Convolution 
^ ^ Design Considerations in the Microwave Transition Analyzer, by Michael Dethlefsen and John 



A. Wendler 



Editor Hn ' f r jo ,i' • Associate Editor ark I I nam • Publication Production Manager. Susan E '.Vr-alti • Illustration Heneell Pighin, 
Typography/Layout • Test and Measurement Organization liaison J Michael GDSpe 

Advisory Board William W B'nyvn InreuiatedCuvui! business Division. Santa Clara Cantowia* Marry Chriu. Mrcrrrniivrr fct/irtnlrtp) Division, Santa Rosa California* 
RajesriDesai Commert rat Systems Division Cupertino. California * Gary Goulon ilPlaboralones PoinAlto California* Jim Grady. Wallliam Division. Wallham 
Massachusetts* Mart J Harlme. Systems Teclinotegv Division Basewlto. California* Bryan Hcog tain Stmvhs Instrument Dmsioit. Everett Washington * Royei L 
Junrjerman. Mictowove Technology Division Santa Rosa. Caufnniia* Pai.laH Kanaroii. intiot Components Pulsion, Corvalhs Oregon* Tt-orna^r Kraenter. Colorado 
Sprinns Division. Colorado Springs. Colorado* RubvB Lee tv'elwurlied Svstemi Group. Cupertino California * Bill Lloyd. HP laboratories Japan Havvasah. Japan* 
Alfred Maute. Waldtjronn Analytical Division Watdbro/m Germany* Michael P Mouie. Measurement Systems Division. Loveland Colorado * Shallev 1 Moore San 
Diego Primer Division San Diego. Catilonna * Dona I Morrill, Worldwide Customer Support Division. Mountain View. CdlHotnia * William M Mowson. Open Systems 
Satmm Division. Chnlrmttm Uttuduaais* Stay*" J. Narcito. WlSystems Dmsron. loveland. Colorado* Raj Bra. Software- Technology Division. Mountain Mr* 
Calitnmra* Han Tran Pima. Asia Penpiierals Division. Strgapwe* Kenneth 0 Poutton. HP Laboratories Palo Alto. California * Guntor RieDesoli Bbblingen Instruments 
Division. Boblmgen Germany • Marc J Sabaraifa Scrams rerhnrj/orfc' Division. Port Collins. Colorado * Mchae! B Saunders. Integrated Circuit Business Division. 
Corvallis Oregon* Philip Stemon. HP laboratories Bristol. Bristol. England* Stephen R UivJv. Systems Technology Division fort Collins Colorado* KotCIn Yartagawa 
Knee Instrument Division Kobe Japan • Ounmii C Vcrk Cnrvatty Division Corvaltis. £7regrin»BarDara/'mmpr. Corporate cnurneermg PaloAltn. California 



ciHewett'Packard Company 199V Printed in U.S.A. 



The Hewlett-Packard Journal is O'Wed on recycled papei 



( Iclriltcr W.K1 Hewlett-Packard .liiittital 



I Copr. 1949-1998 Hewlett-Packard Co. 



72 
76 



A Visual Engineering Environment for Test Software Development, by Douglas C Beethe and 
William L Hunt 



Object-Oriented Programming in a Large System 




Developing an Advanced User Interface for HP VEE, by William L Hunt 



HP VEE: A Dataflow Architecture, by Douglas C. Beethe 



A Performance Monitoring System for Digital Telecommunications Networks, by Giovanni 
Nieddu, Fernando M. Secco, and Alberto Vallerim 




G-Link: A Chipset for Gigabit-Rate Data Communication, by Chu-Sun Yen, Richard C. Walker, 
Patrick T. Petruno, Cheryl Stout, Benny W.H. Lai, and William J. McFarland 



| Bang-Bang Loop Analysis 



Departments 



4 In this Issue 

5 Cover 

5 What's Ahead 

100 Authors 



The Hewlett- Packard Journal is published bimonthly by the Hewlett-Packard Company to recognue technical contributions made by Hewlett-Packard 
IHPI personnel While the information lound m this publication is believed to bo accurate the Hewlett- Packard Company disclaims all warranties ol 
merchantability and htness lor a particular purpose and all obligations and liabilities lor damages, including but not limited to indirect, special, or 
consequential damages, attorney's and expert's lees, and court costs, arising out of 0' in connection with this publication 

Subscriptions The Hewlett-Packard Journal is distributed tree ol charge to HP research, design and manufacturing engineering personnel, as well as to 
qualified non-HP individuals, libraries, and educational institutions Please address subscription or change ol address requests on printed letterhead for 
include a business cardl to the HP headquarters office in your country or to the HP address on the back cover When submitting a change ot address, 
please include your /ip or pustal code and a copy of your old label Free subscriptions may not be available in all countries 

Submissions Although articles in the Hewlett-Packard Journal are primarily authored by HP employees, articles Irom non-HP authors dealing with 
HP-related research or solutions to technical problems made possible by using HP equipment are also considered lor publication Please contact Ihe 
Editor before submitting such articles. Also, the Hewfoti-Packard Journal encourages technical discussions of the topics presented in lecent articles 
and may publish letters expected to be ol interest to readers Letters should be brief, and are subiect lo editing bv HP 

Copyright 1 199? Hewleft-Packard Company. All rights reserved. Permission to copy without fee all or part ot this publication is hereby granted provided 
thai I) the copios are not made, used, displayed, or distributed tor commercial advantage. 21 the Hewloti-Pockard Company copyright notice and the title 
ul the publication and date appear on the copies, and 31 a notice stating that the copying is by permission uf the Hewlett-Packard Company. 

Please address inquiries, submissions, and requests to Editor, Howlett Packard Journal, 3200 Hillview Avenue. Palo Alto, CA 94304 USA 



© Copr. 1949-1998 Hewlett-Packard Co. 



i fctobci l!i!L' Rewlctt-Pncjoird Journal 



In this Issue 



A protocol analyzer is an instrument for monitoring and interpreting the data at a 
point in a data communication network, along with the synchronization, error 
correction, and control information that accompanies the data. The definition of 
the correct form for all of this information is called a protocol, and many differ- 
ent standard protocols exist. Trouble on a network is often caused by deviations 
from the correct protocol, which may or may not be caused by hardware fail- 
ures. A protocol analyzer is supposed to help the network troubleshooter find 
such problems and restore service quickly. In its approach to this task, the HP 
4980 Network Advisor family of personal-computer-based protocol analyzers 
automates much of the work of interpretation and fault analysis that traditional 
analyzers have left to the troubleshooter, offering both protocol commentary and expert system support 
for the first time. Along with the values of various fields and frames, the Network Analyzer tells the user 
when unexpected values or frame sequences occur. A built-in artificial intelligence application called 
the Fault Finder automates the troubleshooting process, using the same rules as expert troubleshooters 
to investigate likely causes and zero in on the problem. The article on page 6 introduces the Network 
Advisor, and the expert Fault Finder system is described in the article on page 11. The software architec- 
ture of the Network Advisor divides tasks between two environments: the general-purpose environment 
(page 21), which implements the user interface, and the analysis and real-time environment {page 29), 
which acquires data and processes it in real time. The Network Advisor recognizes most major protocols; 
it can identify the protocol being monitored and does not need to know it in advance. Recognition and 
interpretation of the syntax and semantics of the various network protocols are the tasks of the Network 
Advisor's decodes facility (page 34). Here the Network Advisor differs from traditional protocol analyzers 
both in the number of protocols it can handle and in its ability to provide not just data but answers to 
protocol problems. 

The protocol analyzer isn't the only approach to maintaining the health of a digital network. Depending 
on the type, size, and importance of a network, distributed monitoring may be appropriate. The HP Model 
E3560 digital performance monitoring and remote test system is designed for continuous surveillance of 
digital telecommunications networks according to Recommendation G.821 of the International Telephone 
and Telegraph Consultative Committee (CCITT). The system provides network managers with statistics 
that reflect the quality of network service and collects alarms that signal failures in network elements. It 
scans data streams at the four main data rates in the European CEPT hierarchy (2, 8, 34, and 140 megabits 
per second), looking for alarms and binary errors. The system's demultiplexing capability can pick out 
and monitor lower-rate tributary streams within a higher-rate data stream. The design of the HP E3560 
system is described in the article on page 89. 

In the article on page 48, the designers of the new HP Model 71500A microwave transition analyzer 

ucSCribc it 85 "a CTOSS between a inQfi-ffeQuefiCy Sampling OSCiiluSCupe, a uyiidniiL ^itjlidi dhdiyiul, diiu 

a network analyzer." Indeed, its block diagram doesn't contain any elements that aren't found in one or 
more of those well-known instruments. The contribution of this new microwave instrument is in its archi- 
tecture, that is, how its components relate to each other, and in its programming. Using periodic sampling, 
analog-to-digital conversion, and digital signal processing in new ways, it brings time-domain analysis to 
microwave component engineers who in the past have had to rely primarily on frequency-domain mea- 
surements. Time-domain measurements are particularly important in pulsed-RF and nonlinear device 
testing, and the microwave transition analyzer is optimized for these applications. Its architecture allows 
it to make magnitude and phase measurements on RF pulses with rise times as fast as 25 picoseconds. 
The article on page 48 introduces this new analyzer, demonstrates many of its new measurements and 
applications, and explains the importance of its high sensitivity, synthesized sampling rate, and stationary 
sampling mode. The design trade-offs and challenges are discussed in the article on page 63. 
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Electronic spreadsheet applications let people express business problems in the familiar rows and col- 
umns of a ledger. With a spreadsheet program, you don't have to know how to program a computer to 
interact with one to solve business problems. For engineers, the analog of the ledger is the block diagram, 
and now there's an analog of the spreadsheet program to free engineers from having to translate their 
block diagrams into unfamiliar computer languages. The HP Visual Engineering Environment, or HP VEE. 
is a software tool that allows users to create solutions by linking visual obiects or icons into block dia- 
grams. The user selects objects from a menu, links them in the way that represents how data flows from 
one to the other, and then executes the resulting block diagram. The article on page 72 explains what HP 
VEE does and how it works. As you might expect, a lot of thought went into making its user interface as 
user-friendly as possible, and that effort is discussed in the article on page 78. Its dataflow architecture, 
described on page 84, is an object-oriented implementation that strictly separates views of an object 
from the underlying model. 

As faster computers are developed, faster data links are needed to interconnect them. There is already 
a demand for serial data links capable of gigabit-per-second data rates, 100 times as fast as Ethernet 
local area networks and ten times as fast as the FDDI fiber optic standard. While gigabit-rate links have 
been used on long-haul telephone networks for many years, their implementation is too costly and com- 
plex for computer use. The HP HDMP-1000 gigabit link chipset (page 103) is the first commercially avail- 
able, two-chip, 1.4-gigabit-per-second, low-cost, serial data link interface. The G-link chipset consists of 
a transmitter chip and a receiver chip and requires no external parts or adjustments. The transmitter 
accepts parallel data and outputs serial data to the link, while the receiver chip reassembles the parallel 
data on the other end. Using a special encoding algorithm called CIMT (conditional inversion with mas- 
ter transition) and an on-off or "bang-bang" phase-locked loop, the chipset automatically maintains dc 
balance in the transmitted data and maintains data synchronization. Among its many other possible 
uses, the G-link chipset has been adopted as the basis for two serial data interface standards. 

R.P. Dolan 
Editor 



Cover 

The HP 4980 Network Advisor can be connected to a network like any other node to monitor the health of 
the network. This rendition depicts a token ring network with several workstations and the Network 
Advisor connected to it. The Network Advisor is represented by a statistics summary screen, which 
summarizes activity on the network for a certain period of time. 



What's Ahead 

Papers on product designs and other topics planned for the December issue are: 
. The HP DesignJet plotter, a large-format Inkjet drafting plotter 

i The HP DraftMaster Plus plotter, a large-format pen plotter that features the SurePlot system for 
improved drawing reliability 
i A multiprocessor HP-UX operating system for HP 9000 computers 
i The EISA input/output extension system for HP 9000 Series 700 workstations 
i A methodology for migrating application software to a client/server, open systems environment 
i Demountable TAB, a new IC packaging technology for modern digital systems 
i 1992 Index. 
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The HP Network Advisor: A Portable 
Test Tool for Protocol Analysis 



This network protocol analysis tool combines expert system technology 
with a comprehensive set of network statistics and protocol decodes to 
speed problem resolution for token ring and Ethernet networks. 

by Edmund G. Moore 



Protocol analysis consists of monitoring and interpreting the 
data communications protocols on a network. The HP 1980 
Scries Network Advisor products arc protocol analyzers 
Offering support for both LAN (local area networks) and 
WAN (wide area networks) technologies. 

The primary users of a protocol analyzer are people respon- 
sible for maintaining communication networks. These users 
fall into two categories: those responsible for maintaining 
service within their own company (private network opera- 
tors) and those who provide service to other companies 
( network service organizations). Protocol analyzers are used 
to solve the most difficult network problems. Since these 
problems account for 2094 of all network failures and usually 
mean degraded network service, the protocol analyzer must: 



Give the user the tools needed to find the problem and 
restore service quickly 

Be easy to use so ihat the user does not have to spend time 
figuring out how to operate the product 
Provide the user with information that is pertinent to solving 
the problem, 

The HP Network Advisor provides features to satisfy 
these requirements. 

Main Features 

The Network Advisor is a portable integrated test tool that 
supports testing of IEEE 802.3 (Ethernet) and IEEE 802.5 
(token ring) network configurations (see Fig. 1 ). The three 
product configurations for the Network Advisor are given 
in Table I. 




Fi«. I, Tlw- HP Network Advisor 
showing the mainframe and the 

folding keyboard and display. The 
display ShOwS an example sum- 
mary Statistics screen in which 
graphical objects such as bar 
chaHs. pie charts, ami gauges are 
used to present information. 
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Table I 

Network Configurations Supported 
by HP Network Advisor Products 

Products Supported Network Configurations 

IEEE 802.3 IEEE 802.5 

HP -IRSOA X X 

HP 4981A X 

HP 49S2A X 

The Network Advisor is made up of two physical compo- 
nents: a PC (personal computer) module and an acquisition 
module. The PC contains all the user interlace functionality 
I keyboard, display, disks. I/O ports). The acquisition module 
is a processing system custom designed to meet the data 
processing requirements of the network under lest. 

The measurement focus of the Network Advisor is rapid 
problem isolation — thai Is, reducing the lime needed to re- 
store the network to operation. Traditional protocol analyz- 
ers focus on providing users with accurate information. On 
a LAN. this can mean tens of thousands of frames of data. 
The challenge for the trouhleshooter is to find the frame that 
is the root cause of a problem. Users of traditional analyzers 
often spend hours examining pages of data looking for a 
due to solve the problem. 

The Network Advisor provides the user with nol only all Of 
the network frame dala, but also abstracted views of thai 
data. These views include: statistics; protocol following,* 
data filtering, protocol commentary, and expert system sup- 
port. Some of these tools exist in other products. However, 
tools like protocol commentary and expert system support 
are new to ihe Industry; 

Traditionally protocol analysis tools have focused on two 
features: protocol decodes and Statistics. Protocol decodes 
are routines that simply lake the protocol header informa- 
tion in Ihe frames and display this informal ion for Ihe user. 
Statistics give Ihe user informal ion on traffic levels used by 
the entire network or by individual devices. In Ihe Network 
Advisor decodes are improved by Interpreting Ihe header 
information. I'sers are lold nol only the v alue of a field, bul 
also the expected value. Additionally, Ihe Network Advisor 
keeps Hack of protocol slate information, allowing the Net- 
work Advisor to tell users when unexpected sequences of 
frames occur. Both Interpretation and stale informal ion are 
new features for a protocol analyzer. 

Statistics in Ihe Network Advisor are designed to provide 
Ihe user with an easy-to-undersland summary view of Ihe 
network. I sing the analysis power of the front end and a 
graphical Interface, a great deal of information is displayed 
in a concise, summary formal (see the display in Fig. 1 ). 
Dala on network use. errors, traffic, protocol distribution, 
and traffic level on selected frames is combined into one 
summary display. 

Protocol commentary and expert system support are power- 
ful additions to (ha protocol analysis toolset. A software 

1 ftWMOl following is At piocess nl tallowing Ihe stale ol a connection tuamplns ol stales 
include established, lesequeming data, and reassembling data Protocol tallowing is essential 
loi accurate decoding ol higher laver protocols 



application called a protocol commentator observes the 
protocols in network frame data and distills the data into 
concise events of interest. Expert system support in the Net- 
work Advisor is provided by an application called the Fauli 
Finder, which automates the troubleshooting process. Both 
of these tools are discussed in the article on page 11. 

Other Features 

Besides the new additions lo the protocol analysis toolset 
described above, lite Network Advisor provides some 
traditional protocol analysis features in new ways. 

Mechanical and Ergonomic Features. I "scrs of protocol analy- 
sis tools such as the Network Advisor frequently need to take 
the tool to the problem. For this reason portability and nig- 
gedness are key features of ihe Network Advisor (see Fig. 1 ). 
The folding keyboard and display are well-protected. The 
instrument has a modular acquisition subsystem and the 
assemblies are connected with a single connector. Four 
quarter-turn fasteners provide the mechanical connection, 
making ii easy lo change from one network technology to 
another in a few seconds. 

The Network Advisor is the first HP product lo incorporate, 
active matrix color LCI) technology, t lolor LCD provides the 
user with reduced size anil weight while providing a bit- 
mapped color graphics interface. The color LCD was added 
very late in the project at considerable risk tO product 
introduction. The team did il Without slipping the product 
introduction schedule. Response lo the package concept 
and especially lo the color LCD has been very positive. 

The article on page 1 1 describes Hie mechanical design of 
the Network Advisor. 

Use of MS-DOS. The LAN testing market uses products 
based on Ihe MS-DOS operating system. The D< >S rcquire- 
Rieni imposed a performance problem fur the design team 
because many of Ihe existing DOS-based products could nol 
match the data integrity goals we had set The Network Ad- 
visor design team solved this problem by creating a machine 
thai has two independent environments: data acquisition 
and D< >S. The data acquisition module is custom-built lo 
ensure dala integrity under any user network condition. The 
D< IS module is fully D< )S-compaiible and provides art excel- 
lent user Interface. The two modules interface using dual- 
poll memory, which is mapped into the DOS memory' space 
just like commercial PC I/O cards. 

We gained substantial benefits froiti this dual-module ap- 
proach Since our DOS hardware was heavily leveraged, we 
needed only one full-time engineer for both hardware and 
Bit IS development. The architectural split allows us lo mix 
and match different dala acquisition and DOS engines to 
create multiple price/performance products easily. Finally, 
being fully DOS-compatible allows us to leverage Ihe vast 
amount of commercial soli ware available, particularly 

communications software. 

Data Capture and Run-Time Analysis. Ensuring thai all data 
from the network can be captured, even under worst -case 
loading, is a difficult design task. In addition to data capture* 
the front end (dala acquisition module) has substantial dala 
processing requirements. In a general sense, the Network 
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Advisor is looking al I ho sum of all network traffic Analyz- 
ing all thai traffic would require a processing bandwidth thai 
matches the total processing resources of all networked 
elements. Therefore, the worst-case processing load imposed 
on the analyzer will always outstrip the ability of the instru- 
ment to process it. Instead of trying to process all network 
traffic, the Network Advisor focuses on processing a subset 
or all the network traffic it sees. 

As a test tool, the Network Advisor needs to sec everything, 
but not to process everything. ( ommercial networking chips 
are designed to be used by network nodes and they auto- 
matically reject input thai is outside the specification for the 
network. A test tool must see this out-of-specification data 
(o give the user a complete picture. An HP-developed receive 
engine ensures that the Network Advisor provides the user 
with all the data associated with an error frame. 

User Interface. MS-DOS-based network test products tradi- 
tionally provide a single task model user interface. This 
means that the product allows only one task at a time to 
execute. The Network Advisor provides a multitasking, bit- 
mapped user interface that is mouse- and keyboard-driven. 
Users can have multiple tasks executing simultaneously 
using a windowing environment. Users can start the traffic 
generator (to simulate a problem on the network) while run- 
ning network statistics (to observe what effect the traffic- 
generator has) and the network commentator (to be in- 
formed of any problems that result). All these tasks can run 
simultaneously to help solve a network problem. 

Product Architecture 

As mentioned earlier, the Network Advisor is divided into two 
major environments: a general-purpose environment, which 
is essentially a personal computer, and a data acquisition, 
analysis, and real-time (ART) environment. This division is 
applied to the hardware and software architectures of the 
Net work Advisor. 

Hardware Architecture. The general-purpose portion of the 
environment contains a 20-MHz Intel38GSX microprocessor 
with 8M bytes of RAM. The BIOS and support chip set are 
from Chips and Technology Company and the disks are 
the same ones qualified for use in the HP Vectra PC. The 
internal display is VGA LCD. either grayscale or color. Our 
objective was to create a PC-compatible machine. Since 
the general-purpose environment is a PC, our engineering 
investment was relatively small. Leverage of design and 
components occurred whenever possible. 

The analysis and real-lime environment is based on the 
AMD29000 RISC chip. RISC technology was selected be- 
cause of price/performance concerns. We needed a CPU that 
would have enough bandwidth to perform our run-time anal- 
ysis and we needed to provide enough bus bandwidth to do 
DMA transfers of all the frames into main memory during 
run time. The analysis and real-time environment uses 1M to 
IBM hues uf memoiy tor program execution and data slot- 
age for captured frame data. Program anil data space uses 
2M to 3M bytes of memory. Data acquisition is based on a 
programmable front end that uses Xilinx programmable gate 
arrays. The front end provides framing, pattern recognition, 
run-time pattern matching, run-time frame filtering, statisti- 
cal counters (e.g., frames per second, errors per second, 
etc. ). DMA control, and basic node card functionality (to 



transmit frames and participate in I he network protocol as 
needed). The front end is designed to ensure data integrity 
in the capture buffer under any network condition, valid or 
invalid. The ability to ensure data integrity is an important 
feature of the Network Advisor. 

Software Architecture. The general-puipose environment was 
developed using object-oriented programming. Smalltalk is 
the language used. Smalltalk provides multitasking, memory 
management, object-oriented design support, and support 
for all DOS functions (primarily I/O control). The Network 
Advisor's user interface was written in Smalltalk to imitate 
the OSF/Motif user interface. 1 

The software was developed on IIP Vectra PCs. making the 
port to the target hardware quite simple. Since the software 
team was large, a toolset that allowed multiple users to 
share the code "image" over a network was employed. This 
multiuser tool provided us with a networked development 
environment. 

The analysis and real-time software was also developed 
using object-oriented programming technology, except that 
C + + was the language used. Software was developed on the 
HP-UX* operating system and cross-compiled onto the 
AMD29000. Software development for these modules was 
also a team effort with the code image residing on a net- 
worked HP-UX server. The core of the analysis and real-time 
code was leveraged from another HP project called CONK 
(common OSI network environment ).- CONK is the protocol 
kernel used in IIP workstations for managing networks. The 
capabilities and design of CONK matched the basic tools we 
needed for protocol analysis. 

The analysis and real-time software is described on page 29. 
The software developed to run on the PC and I he general- 
puipose environment are described on page 

Software Management 

Kxcept for the DOS BIOS and the analysis and real-time 
boot and self-test, which arc ROM-based, all the software in 
the Network Advisor is disk-based. Hav ing a DOS-based 
software system has proven to be a major benefit to product 
enhancement and to our customers. During the first year of 
the Network Advisor's life, we created three major upgrades, 
several bug fixes, and a new leveraged product. Suppon for 
all of these changes was based on shipping new disks. 

A DOS-based system does pose some problems. First, there 
is a tendency for users to modify the system configuration 
to add applications, drivers, and TSRs (terminate and stay 
resident programs). Different DOS applications do not al- 
ways peacefully coexist. In addition to software, the ability 
to have different disk drives, different amounts of memory, 
and different CPUs creates a matrix of configurations that 
can be overwhelming. 

Kven if the configuration issue is managed, being DOS- 
compatible means evolving over time. DOS 5.(1 has become 
the standard since our release, and in March 19!)2 we 
changed our shipped configuration to be DOS 5.0 with a 
single disk partition. We still must support our customers 
who still have Network Advisors with DOS 3.3 and multiple 
disk partitions. This creates its own logistical problem. 

(continued on nage 1QI 
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Network Advisor Product Enhancement Philosophy 



Our intent was to release an initial Network Aflvisor product with a credible set of 
features as auickiy as possible The initial feature set did not provide all of Die 
capabilities we wanted it did provide enough capability to solve customer problems 
We wanted to provide releases rji additional software on a frequent basis I two or 
three times a year! The initial release occurred in July 1991 and smce then we nave 
lad new releases kn November 1991. March 1992. July 1992. and August 1992 
Each release added additional capabilities m all areas of the product including 

Fault Finder. The Network Advisor can do automatic troubleshooting via the fault 
Finder on the following network media. 

IEEE 802 3 Media Access Control IMACI Hardware 

IEEE 802 5 MAC Hardware 

Commentators. Commentators provide a high-level abstraction of protocol activity 
Unlike a protocol decode, which displays all of the fields associated with a partic- 
ular protocol, the commentator reports on the meaning of a frame in the context of 
the service being provided by the protocol The Network Advisor provides the 
following commentators 

Ethernet Novell Commentator 

Ethernet ICMP Commentator 

Token Ring Commentator 

Token Ring Novell Commentator 

Token Ring IBM LAN Manager Commentator 

Decodes. The Network Advisor decodes most industry-standard protocols A 
decode enables protocol experts to examine the contents of a protocol data trame 
111 detail The Network Advisor provides the following decodes 

Ethernet/LLC 802.3 

IEEE 802 2 SNAP ELAP Token Ring 

IEEE 802.2 Token Ring MAC SNAP 

Appletalk Address Resolution Protocol 

Datagram Delivery Protocol 

EtherTalk Link Access Protocol 

AppleTalk Transaction Protocol 

Routing Table Maintenance Protocol 

AppleTalk Echo Protocol 

AppleTalk Name Binding Protocol 

Banyan Vines Internet Protocol 

Vines Address Resolution Protocol 

Vines Routing Update Protocol 

Vines Sequenced Packet Protocol 

Vines Internet Control Protocol 

Vines Interprocess Communication Protocol 

DECnet Data Access Protocol 

Session Control Protocol 

Data Access Protocol 

Network Services Protocol 

DECnet Routing Protocol 

Local Area Transport Protocol 

Novell Netware Code Piotocol 

Sequenced Packet exchange Protocol 

Internet Packet exchange Protocol 

IBM PC IAN NetBIOS Protocol 

Server Message Block Protocol 

TCP/IP Telnet Transport Control Protocol 

User Datagram Protocol Internet Protocol 

File Transfer Protocol 

Internet Control Protocol 

Address Resolution Protocol 

OSI CLNP 

OSI ES-IS 

OSI TP4 

SNA 

NetBIOS 



XNS Internetwork Datagram Protocol 
Sequence Packet Protocol 
3COM NetBios Protocol 
Server Message 8 lock Protocol 

Statistics. The Network Advisor's statistical measurements give the user a 
graprwal view of anna) network performance parameters a-id network users 



Ethernet Summary Statistics 
Ethernet Node Statistics 
Ethernet Top Talkers 
Ethernet Top Error Sources 
Ethernet Vital Signs 



Token Rmg Summary Statistics 
Token Ring Station Statistics 
Token Ring Top Talkers 
Token Ring Top Error Sources 



Canned Tests. Canned tests provide a set of powerful troubleshooting tools for 
performing tasks such as testing for connectivity and finding active stations Many 
of the canned tests stimulate the network to simulate network devices The Net- 
work Advisor provides the following canned tests 

Ethernet Transceiver Test 
Token Ring List Configuration 
Report Servers Token Ring List 
LAN Managers Token Ring List 
NETBIOS Stations Token Ring List 
Novell Stations Token Ring List 
Ring Error Monitors Token Ring List 
Ring Parameter Servers Token Ring List 
All Bridges Token Ring List 
All Stations Token Ring List 
Calculate Ring Length 
Token Ring LDbe Test 
Token Ring Request Station ID 
Token Ring Station Adapter Status 
Token Ring Active Station List 
Novell Find Nearest Server 
Novell Get List of Servers 
Novell View Notles 
Novell Server Ping 
Novell Node Ping 

Novell Determine Connected Networks 
TCP/IP ARP Request 
TCP/IP Ping 

Node Discovery. The discovery measurement identifies active nodes on the 
netwuik by observing network traffic The measurement can Rod and display 
MAC (media access controll and network addresses. The binding of MAC and 
network addresses clearly shows the activity of routers in the network 
Discovered nodes can be merged into the system nodehst 

WAN Capability. A data acquisition module that contains the HP 4957 WAN 
analyzer functionality has been implemented as a PC I/O caid Using the Network 
Advisor's DOS capability, this card gives customers WAN support, without any 
additional software 

FDDI Capability. A data acquisition module is available that interlaces to FDDI 
(fiber distributed data interface) networks This module was implemented in the 
same spirit as the IEEE 802 3 and 802 5 modules— ensure data integrity under any 
network condition 

Disk Drives. Dunng development, we had planned to use 40-Mbyte and 
80-Mbyte hard disks However by the tune we introduced the product, typical disk 
densities lor PC hard disks had changed 150 Mbytes to 105 Mbytes were typical 
sizes) We switched lo 80-Mhyte and 160-Mbyte disk drives during the fust year 

Intel486 CPU. We created an Intel486 version of the CPU to keep current with 
CPU technology The Network Advisor has been designed to allow adaptation to 
new CPU and I/O technologies 
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Conclusion 

Tin- Network Advisor has created a new standard in tin- 
LAN test marketplace. It is a tool that not only collects and 
supplies users with network traffic data, hut also extracts 
pertinent answers from the volumes of data. Asa DOS- 
based system, the Network Advisor offers compatibility, 
flexibility, and a clear path for evolution. As an instrument, 
the Network Advisor offers unprecedented performance in 
data capture and analysis and brings IIP quality and data 
Integrity to the LAN marketplace. 
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Embedding Artificial Intelligence in a 
LAN Test Instrument 



The knowledge and processes used by a skilled LAN troubleshooter are 
built into an interactive expert system application that runs on HP 4980 
Series Network Advisor protocol analyzers. 

by Scott Godlew. Rod Unverrich, and Stephen Witt 



The capabilities or artificial intelligence techniques are pro- 
vided in the HP 4980 Series Network Advisor protocol ana- 
lyzers by a software application called I he Fault Finder. It is 
a rule-based expert system thai is built around a blackboard 
architecture. 1 ' 2 The rules, written in PROLOG, 3 invoke Net- 
work Advisor measurements (statistics, decodes, and ap- 
plications) that are available to the user. The Fault Finder 
allows the user to control and view the iroubleshooling pro- 
cess at a detailed single-step level or al a fully auloniated 
level. It also includes an explanation facility Ihal describes 
the logic used to solve a specific problem, a definition of the 
problem, and a description of the actions required lo remedy 
the problem. 

This article will discuss LAN troubleshooling, automated 
iroubleshooling using expert systems, the Faull Finder, Ihe 
architecture of the Fault Finder, and a typical problem 
solved using the Faull Finder on a loken ring network. 

Expert I roubleshooters use a paradigm of making observa- 
tions, forming hypotheses, and proving or disproving those 
hypotheses until a problem is found (see Pig 1 I The Fault 
Finder uses this same paradigm. A description of how this 
model is employed by the Fault Finder is mentioned 
throughout this paper. 

LAN Troubleshooting 

For the last ten years LAN (local area network) trouble- 
shooters have relied on LAN protocol analyzers that provide 
a variety of decode measurements, statistical measure- 
ments, and active measurements. This is a manual process 
Ihal depends on the user's knowledge of the instrument, the 
network, and typical problems that occur on that network. 
These analyzers require a user lo interpret results and select 
subsequent measurements. 

LANs provide high-speed packet switching within buildings 
or campus fac ilities. They include CSMA/CD baseband net- 
works, token ring networks, and broadband networks. This 
paper addresses Kthernct (IEEE 802.3) and token ring 
(IEEE 802.5) networks. LANs are challenging in their trou- 
bleshooting requirements because they operate at high 
speed, problems emerge and escalate in real-time, and the 
environment is very complex. Problems can result from 
poorly architected networks, improper device configura- 
tions, faulty cabling or connections, broken devices or 
printed circuit cards, or incompatible software. A typical 



IAN can have several network operating systems and proto- 
col stacks. Troubleshooting a network problem requires 
integrating pieces of data or clues from a variety of sources 
and using the acquired data to hypothesize and prove prob- 
lems. Problems that do not cause hard failures but instead 
only cause performance problems may often go undetected. 

Network diagnostic tools have evolved in the same way as 
networks. Early diagnostic tools included workstation utili- 
ties, cable measurement instruments, and simple protocol 
analyzers that provided decoding of protocol packets. Net- 
work troubleshooting requires sequencing through different 
measurements, using the results of one measurement to 
select and program the next measurement . As net works 
became more complex, the problems became more com- 
plex. This increasing complexity created a need for more 
sophisticated tools lo enable network managers to solve 
problems ralher than relying on hit or miss solutions, or in 
some cases simply living with the problem. 

Network managers and technicians solve many problems by 
relying on knowledge of their specific network and its com- 
ponents and by relying on their troubleshooting experiences. 
For example, a net work technician can quickly identify a 
miscon figured node card by observing the card's receiver 
congested soft-error frames on the token ring net work. 

Expert trouble-shooters use a mental model or paradigm for 
troubleshooting. Some perform this at a decidedly conscious 
level by diagramming the troubleshooting process. Others 
perform it subconsciously, following "what feels right." In 
either case the same basic process is used. They start by 
making observations of Ihe situation. It doesn't matter what 
problem is being solved, be it a ruptured appendix, a faulty 
carburetor, or a duplicate IP address — all trouble.shoot.ers 
(doctors, auto mechanics, and network managers) use the 
same process. They use these observations lo formulate 
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Fig. 1. The observe, hypothesize and prove (or disprove) trouble- 
shooting process used in the Fault Finder. 
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hypotheses Of what problems might exist. Thou they per- 
form tests to prove or disprove the hypotheses. Finally, once 
a problem is proved they remedy the situation. This model is 
shOwn in Fig. L 

Protocol analyzers offer a variety of measurements for solv- 
ing problems. Decodes provide descriptions of individual 
packets on the networks. Statistical measurements provide 
overviews of network trends such as utilization, errors, and 
protocol use. Indiv idual applications provide utilities for a 
variety of functions such as creating an active station list, 
reading the status of network adapter cards, and testing the 
media. These are powerful tools in the hands of an expert. 
However, these analyzers have two major shortfalls. First, to 
solve difficult problems an expert user is usually required. 
Second, they require human intervention and cannot com- 
plete the troubleshooting task in an automated fashion. Arti- 
ficial intelligence offers a desirahle solution to hold of these 
problems. It allows an analyzer to monitor the network con- 
tinually for problems and log the results for later perusal by 
a network manager. It also provides the means lo build the 
knowledge of many troubleshooting experts into a tool that 
is widely available to network managers. 

Automated Troubleshooting Using Expert Systems 

Artificial intelligence (AI) solutions that are declarative in 
format and conventional solutions thai are procedural in 
format can be used together to solve networking problems.* 
Expert systems (one branch of AI), in a broad sense, are 
programs that are designed to behave as a human expert in 
a particular Held. Expert systems are particularly useful for 
problems like networking in which complete information 
about a problem is not known when the program begins 
execution. Expert systems gather additional, pertinent in- 
formation as they execute. Conventional, procedural pro- 
grams usually execute in a sequential fashion through a set 
of troubleshooting trees and can lake more time and execute 
incorrect branches. Expert systems gather information after 
an event and use it to explore multiple problems in parallel. 

The requirements for an expert system troubleshooting tool 
me somewhat diverse. First and foremost the expert system 
must discover network faults and make observations about 
the network. A primary goal is to diagnose common network 
problems quickly, allowing the human user to concentrate 
on more difficult and obscure problems. To do this, the ex- 
pert system must be cognizant of the network structure, the 
protocol environments, the diagnostic tools available, and 
the troubleshooting methods that will solve the problem 
quickly. Thus, an expert system tool for network trouble- 
shooting must be able to do the following: 
Measurement Interface: 

Perform diagnostic functions such as generating station 
lists, testing connectivity, and performing loopback tests 
Confirm the existence of a hypothesized fault by executing 
active measurements such as token ring station adapter 
status 
Automated Operation: 
Monitor the network for real-time problems as opposed 
to gathering information mid postprocessing it in a batch 
fashion 

In ihe conlenl of computet ptogtams, p<oceduies tell a system specifically hnw to do a task 
and declarations tell a system genetally wtiat to do 



Execute in an automatic, unattended fashion to solve 
intermittent faults, monitoring suspect rings or segments 
continuously 

• Ease of I "so: 

Provide Ihe user with an interpretation of dala by suggest- 
ing actions, drawing conclusions, and explaining advice 
Provide an audit trail of suspected problems, measure- 
ments executed, and problems found to educate Ihe user 
and lo suggest possible problems that the expert system 
could not solve 

Generate alarms and log data to notify the user of proven 
faults and provide the necessary' information lo prove that 
the problem exists 

Incorporate user inputs by including information thai 
Ihe user already suspects about Ihe network (such as 
performance problems ) 

• Topology: 

Gather and incorporate network topology information 
Gather error information thai is being reported on Ihe 
network and learn about the configuration of the network 
Gather and incorporate network baselines lo determine 
what is normal behavior on Ihe network and compare the 
current operation against normal behavior. 

It is critical that an expert system that augments a users 
troubleshooting met hods behave in a manner thai the user 
can understand. Making observations, forming hypotheses, 
proving faults, and determining actions to take are critical 
troubleshooting steps that a network manager can under- 
stand and relate to. 

Nole that expert system lools could also be used to optimize 
performance, analyze network accounting informal ion, per- 
form network management functions, audit for security 
violations, and provide information for network planning. 
However, in this article we are only concerned with an ex- 
pert system tool whose purpose is to diagnose operational 
faults on a local ring or segment of the network. 

The Fault Finder 

The Fault Finder is an expert system that executes as a soli- 
ware application on the Network Advisor family of prod- 
ucts. It uses troubleshooting methods that are modeled after 
expert users in the field, applying knowledge of known net- 
work problems, ll programs and executes measurements in 
the same way thai an expert user would, taking advantage of 
the powerful measurement sel of Ihe Net work Advisor. 

The Fault Finder w as designed lo provide the user with a 
high degree of Interaction with the instrument and a detailed 
view of the activities of Ihe Fault Finder as it attempts to 
solve a problem. This was considered critical because many 
nelwork problems cannot be diagnosed to completion. In 
these cases il is important lo give the user an audit irail and 
provide as much information as possible that might be perti- 
nent to solving the problem. For example, suppose the Fault 
Finder suspects a broken transmit wire on a network inter- 
face card with address 10005A74624A. but this suspicion 
proves lo be false. The fact that the Fault Finder was Inves- 
tigating a potential problem on a certain station on the net- 
work might be of interest to the network technician. The 
technician might be able to correlate the Fault Finder data 
with previous troubleshooting data and use this synthesis of 
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information lo solve Ihe problem. In addition to suspected 
problems. Ihe Fault Finder records measurements it has 
executed. Such information may help an expert hone in on 
the real problem. This audit trail can also be used as an 
educational tool by the novice troubleshooter. 

The Fault Finder's main screen has three tiles that map 
directly to the observations, hypotheses, and proven faults, 
which are Ihe mainstays of the expert 's troubleshooting pro- 
cess (see Fig. 2). The Fault Finder starts by running mea- 
surements that provide observations for the troubleshooting 
process. These observations are posted to the first window. 
The rules in the know ledge base are executed and hypothe- 
ses are Conned. For example, if a statistical measurement is 
nin that observes that the rate of broadcast frames on an 
Ethernet network exceeds a baseline, the Fault Finder will 
hypothesize several possible problems including a duplicate 
IP address and a miseonfigured IP broadcast address. The 
Fault Finder will then perform further measurements such 
as a ping (internet control message protocol (ICMP) echo 
request) or an IP (internet protocol) decode to determine 
whether a problem exists. If the problem exists, it is posted 
to the Faults Found window, the window is turned red, and Ihe 
user is notified with an audible alarm. 

The user can nun the Fault Finder in sev eral different modes. 
The single-loop mode runs once through Ihe possible fault 
indicators looking for problems. It follows all results lo a 
conclusion and then stops. The Fault Finder can run in a 
cotuinuous-loop mode in which it repeatedly cycles looking 
for faults. The Fault Finder will also accept user symptoms 
to allow the user to direel the search by including what is 
already known or suspected about a network fault. Possible 
symptoms include poor performance, cannot connect, and 
suspected Novell problems. These symptoms cause the Fault 
Finder lo focus its search initially on suspected problem 
areas. When appropriate, the Paul) Finder will request the user 



to input the results of cable scanning measurements to aid 
in diagnosing physical media problems. 

The Fault Finder accesses Network Advisor measurements 
in the same way that Ihe user would. For manual use the 
user is presented w ith a window containing a list of all the 
Network Advisor measurements sorted by categories. The 
Network Advisor allows the user to sele<T multiple measure- 
ments and execute them simultaneously. Each measurement 
includes a paiameterization window for setting up the con- 
figuration. For example, a ping measurement requires the 
user to specify the internet addresses for the Network Advi- 
sor and the target node for the ping, and the timeout value 
(see Fig 3). The Fault Finder automatically selects measure- 
ments, provides parameterization, executes the measure- 
ments, and obtains the results. A user performing this task 
manually can often make a mistake, which can lead to a 
false diagnosis and many hours of invalid and fnist rating 
troubleshooting. 

Network troubleshooting depends on the concept of under- 
standing normal behavior on a network and comparing die 
observed results with Ihe normal expected behavior. The 
Fault Finder uses this same approach by keeping a baseline 
file that documents the expected values for the measure- 
ments to compare with the actual results. Each measurement 
compares its actual results against the expected results in 
the baseline file. 

The Fault Finder uses prioritization and certainties to guide 
itself through the troubleshooting process. Prioritizations are 
implemented by assigning a severity and a frequency to each 
problem. This means that Ihe Fault Finder will pursue more 
serious problems first For example, a broken file server is a 
more serious problem than a broken node and will be inves- 
tigated first . Certainties refer to the confidence levels as- 
signed to the Fault Finder's results. Each Fault Finder result 
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is rated as low, medium, or high ( sec I he |High| designation 
given to the fault found in Fig. 2). Problems (faults) thai can 
be conclusively confirmed are given a high confidence and 
problems that might be one of several possibilities and can- 
not be diagnosed further are assigned a low confidence. 

The Fault Finder provides the user with a very fine level of 
control over the troubleshooting process. Allowing the user 
to interact with the Fault Finder was a key design objective. 
Expert systems that appear as a black box to the user are 
not appropriate for interactive network troubleshooting. 
The Fault Finder normally runs in an automatic mode cy- 
cling from observations to hypotheses to proven faults. This 
is very useful for verifying the norma] operation of the net- 
work, or for a mode of debugging in which the user might 
look for intermittent problems on a network before they 
become catastrophic and degrade the network. Hie Fault 
Finder also provides several manual modes of debugging, 
which are useful for reactive troubleshooting to investigate 
specific failures. 

Once the Fault Finder has executed and discovered a fault 
on the network, the user must perform the final step of 
troubleshooting — correcting the fault. Simply identifying the 
fault is not enough if the user does not know how to remedy 
the problem. The Fault Finder includes a comprehensive 
explanation facility that explains the troubleshooting pro- 
cess and describes the actions to be taken to fix the prob- 
lem. Any line entry in any of the three tiles can be high- 
lighted and selected to invoke the explanation facility. The 
explanation facility is Implemented via the knowledge base. 
Each entry includes a definition, a reason, and an action. 
Fig. 4 shows an explanation window that explains the neces- 
sary action to fix the problem of a station Inserting in the 
network at the wrong speed. 
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Fault Finder Architect ure 

The Fault Finder architecture (see Fig. •">) was designed with 
four main objectives. First, the Fault Finder must be able to 
operate the instrument in place of the user (the network 
manager). This means that the Fault Finder needs to initiate 
and receive results automatically from instrument measure- 
ments in a knowledgeable way. Second, the Fault Finder 
must actively detect and investigate faults in a manner that 
will allow users to accept its conclusions and understand its 
actions. Third, the Fault Finder must be able to support 
knowledge about multiple protocol domains and adapt In 
varying target networks depending on the needs of our cus- 
tomers. Finally, an inability to complete the diagnosis of one 
potential fault should not prevent the diagnosis of other 
potential faults. 

The inference engine provides the core knowledge process- 
ing capability and sets the stage for relating the other com- 
ponents in terms of their ability to provide information to 
Support inferencing. The blackboard provides a mechanism 
for allowing multiple sources and sinks* of information to 
cooperate and allows the user to get information about how- 
data is synthesized in the Fault Finder. Measurements and 
user input provide two examples of information source 
modules that are not knowledge-based, but procedure-based. 

Inference Engine. An inference engine executes know ledge 
aboul a particular domain. During execution, high-level in- 
formation is synthesized from measurement data, user input, 
and the knowledge base. The synthesis can be driven by the 
need to use the high-level data for some other purpose or 
the availability of sufficient lower-level data to complete the 

' Sources oenerate inlormalipn and sinks receive inlormalion 
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synthesis. In either case, the knowledge that is executed 
describes how the synthesis takes place. 

The Fault Finder uses a form of knowledge representation 
known as r ules. These rules describe the necessary state of 
information to be able to synthesize higher-level informa- 
tion. The rules in the Fault Finder have the following three 
main pails: 

The consequent (describes the information to be synthesized 
by the rule) 

The antecedent (describes the required preconditions thai 
will allow synthesis to occur) 

The parameters (constrain how the inference engine is 
allowed to use the rule). 

The following rules are used to identify a stal ion inserting in 
the network at the wrong speed These rules show the con- 
sequent, the problem definition, and the antecedent, which 
includes the preconditions (forward chaining) that must be 
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satisfied and the informal ion needed to prove (or disprove) 
the hypothesized problem (backward chaining). 

;Problem description 

problem! 

name! InsertWrongSpeedProblem I 
nlsNamel 'Inserting Wrong Speed' I 
eventTypel *FaultEvent ) 
frequencyl 50 I 
severity) 50 ) 

definition! 'Station inserting at the wrong speed means the network 

interface card (NIC) is not configured to the proper data 

rate for the attached local ring,' I 
solution! 'Check the settings on the network interface card on the 

stations between the indicated fault domain. After configuring 

the network interface card correctly, re-cycle the station power. 

For example, on an IBM Token Ring Network 16/4 Adapter 

(Network Interlace Card), check the settings of the dip switches. 

Dip switch 12 should be set 10 the appropriate data rate (4 Mbps 

dip switch On and 16 Mbps dip switch Off I. ' ) 
hypoTextl 'Station may be inserting at wrong network speed in domain 

of %?%address% and %?%addressNAUN%. ' I 
concText! '%+%Station inserting at the wrong network speed in the fault 

domain of %%?+%addressNAUN%%*% and %%?*%address 

%%+%.%%-%Station 

not inserting at the wrong speed in the fault domain of 
%%?-%addressNAUN%%-% and %%?-%address%%-%.% ' ) 
parameters! 
I address #node 'hypothesis " " I 
I addressNAUN *node ^hypothesis " " I 



;Forward Chaining Rule 

hypothesize! 

These are parameters 
name! hWrongSpeed ) 
cost! 50 I 
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confidence! 100 ) 

explanation! II a station fails to insert onto the local ring properly, 
then it is possible the station's network interface 
card (NIC) is set to the wrong speed ' I 

.Consequent 

logicTextl 'InsertWrongSpeedProbleml ?address ?addressNAUN I - 
;Antecedent 

beaconingMonilor) useBaselines 'time ?beaconAddress 

?beaconAddressNAUN) 
performl ?tmpl ?st "ar.put:" #lancTokenRingLastBeaconingAddress 

?beaconAddress) 
performl ?tmp2 ?st "atput" #lancTokenRingl_astBeaconingAddress 

NAUN?beaconAddressNAUN) 

streamingBeaconsMonrtorl useBaselines ?time 'beaconStreamAddress 
?beaconStreamAddressNAUN ?) 

newActiveMonitorl useBaselines 'time 'addressActiveMonitor 
?addressNAUNaddressActiveMonitor ?l 

topology lasTokenRingNode | 'addressStr ] ?address | 

topology lasTokenRingNode | ?addressNAUNStr ] ?addressNAUN I 

stopAIIMeasO 



;Backward Chaining Rule 

backwardl 

;Parameters 
namel cWrongSpeed I 
costl 50 I 
confidence! 100 ) 

explanation) 'If a station fails to insert onto the local ring properly, 
then it is possible the station's network interface 
card (NIC) is set to the wrong speed. The inserting 
station will attempt the insertion, but will be unable 
to synchronize with the incoming signal and therefore 
remove itself from the local ring. The station may 
try multiple insertions before removing completely ' ) 

;Consequent 

logicTextl 'InsertWrongSpeedProbleml ?address ?addressNAUN I - 

;Antecedent 

mdbParm ItxMeasTimeout ?txTimeout ) 

perform I ?addressStr ?address tokenRingAddress ) 

adapterMeasI ?addressStr ?tx Timeout ?resultl ) 
size! ?resultl ?resultSizel I 
gtl ?resultSizel 0 I 

perform I ?addressNAUNStr 'addressNAUN tokenRingAddress I 

adapterMeasI ?addressNAUNStr ?txTimeout ?result2 I 
sizel ?result2 ?resultSize2 ) 
gtl ?resultSize2 0) 

•I 
I 

The Fault Finder rules arc modeled alter PROLt )( i. so Hie 
consequent is simply a predicate that represents ihc goal or 
information to be synthesized. The predicate has a name 
that represents the type of information being synthesized 
and parameters thai determine the specific information. For 
example, in the rule cWrongSpeed the predicate InsertWrong- 
SpeedProblem tells us if the wrong speed is set on the adapter 
card at some address. This would be synthesized by gather- 
ing data via the antecedent predicates and incorporating this 
data into the consequent. 



In the antecedents of the example rules, the conditions are 
simply ANDed together. Like IF statements in mosl program- 
ming languages, other logical operations can be performed 
The inference engine allows patients to be specified in place 
of constants, and Ihc condition may succeed multiple limes 
depending on how many pieces of informal ion match the 
patterns. This allows knowledge to be represented in a gen- 
eral way. Without knowing ahead of lime how many situa- 
tions might meet the criteria or the specific names or values 
of parameters. 

The execution of a rule can be driven by forward or back- 
ward chaining operations. In forward chaining. Ihe inference 
engine is presented with one or more network conditions 
(e.g., network is sluggish). This data will drive the execution 
(jf rules thai depend on this data. In backward chaining, we 
start with a result or conclusion to be proved H ue or false 
(e.g.. station inserting at the wrong speed) and work back 
through the rules (gathering informal ion along the way) to 
find the problem or condition causing the given result. 

Blackboard. The blackboard allows multiple modules 
(sources and sinks of data) to work together. It also main- 
tains an Information structure thai allows greater accessibil- 
ity and storage of history dala aboul how the informalion is 

synthesized or generated 

Thi' blackboard serves as a clearing house for all informa- 
tion in the F&uil Kinder. It determines which module should 
be called to perform further informalion synthesis or dala 
generation. When a moduli' needs information to complete 
its synthesis, the module requests the information via Ihe 
blackboard, and ihe blackboard determines which module 
can act as a source for lhat informalion. When 'lata becomes 
available asynchronously, the dala is distributed lo Ihosc 
modules thai could perform further synthesis based on lite 
data. The modules are responsible for notifying the black- 
board of their specific needs. 

Requests and Responses. In the Fault Finder s blackboard, 
requests for informalion are posted lo initiate informalion 
synthesis. For example, if we waul Ihe Fault Under to deter- 
mine Ifa particular fault exists, a module will request infor- 
malion about Ihe fault's existence and then direct the FauH 
Finder to prove (or disprove) the fault. When Ihe Fault 
Finder is observing the network, it may. on its own. decide 
to determine if a fault exists. The conditions that indicate 
the possible existence of a fault cause a request lo be placed 
on the blackboard. 

Responses are the result of investigating a request. When a 
module completes processing a request, one or more re- 
sponses are placed on the blackboard. Multiple matches of a 
patient can generate more than one response. Each response 
has a level of certainty associated with it. which is deter- 
mined from the certainty of the informalion il is based on 
and Ihe confidence of the rule used to perform ihe synthe- 
sis. In Ihe end, a fault diagnosis can be weighed against 
other faults lo determine a priority for correcting the faults. 

Hierarchical Data Abstraction. Bj H ac king requests and re- 
sponses exchanged via the blackboard, a hierarchy of infor- 
mation created by the system can be maintained (see Fig. 0). 
The hierarchical orientation of the information facilitates 
both usability and programmability of the system. 
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Fig. 6. Hierarchical data abstraction built by tracking requests and 
responses. 

Usability is enhanced by using the hierarchy to demonstrate 
to the user the steps taken to reach a conclusion, allowing 
the user to examine why a request was made in the first 
place. The modules that post requests and responses on the 
blackboard are required to provide human readable explana- 
tions related to these postings. The explanations include 
how the information was generated, what the information 
means, and in some cases, what can be done about some 
problematic situation. Because users have control over what 
level of decomposition (hey desire to see. the hierarchy also 
protects them from the need to look at all of the details of 
the diagnosis. The user can select an interesting high-level 
item and pursue some of the low-level details of that item. 

The hierarchy is designed to eliminate dependencies between 
modules. This enhances the ability of knowledge engineers 
to represent knowledge in a way thai is reusable and main- 
tainable. Information from one source can be used by a v ari- 
ety of sinks thai synthesize additional information. If a bet- 
ter way of generating the information is determined, the 
source can be changed without having any impact on the 
sinks. This will allow the product lo evolve over time as 
our understanding of the problem improves and as other 
capabilities of the product evolve. 

Procedural versus Declarative. The inference engine provides 
an environment for executing knowledge about diagnosis. 
This knowledge is represented in a declarative form using 
rules. The rules represent relationships between facts that 
transcend the procedures for proving those facts. However, 
pails of the diagnosis process require the ability to represent 
the procedural aspects of diagnosis explicitly. A procedural 
representation can be thought of in terms of a program writ- 
ten in a language such as C, Pascal, FORTRAN, and BASIC. 

In the Fault Finder, the instrument measurements and user 
Inputs represent procedural components of the network 
diagnosis process. The measurements embody complex pro- 
cesses forgathering data about the network. The user inputs 
allow the user to perform a procedure that is nol easily auto- 
mated. The modules thai provide this procedural capability 
have been designed lo interface with the blackboard in Ihe 
same way as the inference engine. 



Measurements. When a request for data on the blackboard 
can be satisfied by running an instrument measurement, the 
measurement is initiated and its results are posted on the 
blackboard. A simple example w ould be running an adapter 
status measurement. The data requested is the status of a 
particular interface card or the ability to contact the node 
associated with the card. The blackboard forwards this re- 
quest to die measurement module where the adapter status 
measurement is handled. The result of running tiic measure- 
ment is that the status and the basic ability to communicate 
with the node are posted as responses on the blackboard. 

When the results get posted, other modules that need this 
information can proceed with the synthesis of additional 
information. For example, the failure of a token ring station 
adapter status may be just one of the conditions of a rule 
that diagnoses some fault. When the station adapter status 
results are received by that rule, the rule may proceed wilh 
evaluation of the remaining conditions. 

User Input. L'ser input is handled vcr> similarly to measure- 
ments. When information is requested from the blackboard 
that the user input module is capable of generating, the 
blackboard passes the request to the Input module handling 
the user request. A description of the information and how 
to determine the correct response is provided as part of the 
user interface interaction. The user will perform the proce- 
dures required to determine the correct response and then 
enter or select an answer. The module that requested the 
information will then proceed with its synthesis. 

Flow of Control. To satisfy the design objectives stated earlier, 
the flow of control within the system must be carefully con- 
trolled. The inference engine has a number of control How 
characteristics that can be controlled including forward and 
backward chaining, cost and confidence parameters for 
rules, and the urgencies of requests placed on Ihe black- 
board. One of the key characteristics of the inference engine 
is its ability lo suspend threads of inference while some of 
Its requests are blocked to pursue other threads of inference. 

Multithreaded PROLOG. When the inference engine requests 
information from the blackboard, there is no guarantee that 
the informal ion will be available or that the request will be 
immediately selected as the next request to satisfy. The in- 
ference engine must be able lo suspend its inferencing re- 
lated to a request until the response is available Also, while 
wailing for a response, Ihe inference engine must be able to 
initiate oilier chains of inference lo satisfy other requests il 
receives. 

To make this possible, the blackboard allows context infor- 
mation to be slored with each request This allows a request- 
er lo resume synthesis when Ihe requested data becomes 
available. When Ihe blackboard notifies a module w ilh the 
new information, the context information is returned lo Ihe 
module. For cases in which multiple responses match a re- 
quest, the context information is copied lo create an equiva- 
lent but separate context for each response. This allows all 
of the backtracking capability of PROM HI to be provided in 
the blackboard environment. The context information also 
helps when presenting explanations lo Ihe user. 
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Prioritization. When modules request information from the 
blackboard, an urgency level is associated with the request. 
When the request becomes the one with the highest urgency, 
a module is selected to satisfy I he request. The module with 
the lowest-cost technique for satisfying the request is selected 
as the exclusive provider of the response. Rules have mech- 
anisms for passing default urgencies for new requests or for 
increasing or decreasing the urgencies of new requests. Other 
modules can set t he appropriate urgency of requests for 
t heir form of synthesis. Each module must be capable of 
providing an estimate of its cost for any given request. 

Tying Components Together. The inferenc e engine is the key 10 
enabling the Fault Finder lo operate the instrument in place 
of a human user. The rules in its knowledge base represent 
I he ability t o perform a diagnosis of some fault in a net work. 
The inference engine requests information from the black- 
board and causes measurements to be executed or user input 

t o be solicited. 

The blackboard is the key to operating in a manner that is 
understandable and justifiable. Information is stored that 
allows the user lo understand how information is synthe- 
sized and why any particular step was taken. The hierarchi- 
cal nature of the data allows the user to control the amount 
of information being presented. 

The inference engine and the Net work Advisor measure- 
ments allow the Fault Finder to adapt to a variety of proto- 
col domains. A knowledge base with rules about Ethernet is 
combined with a measurement set for Ethernet to allow the 
Fault Finder to find faults on Ethernet networks. The same 
is true for token ring, TCP/IP, Novell, and other domains. 
The knowledge for the various domains can be ( (unbilled 
to address more complex situations. 

The multithreaded nature of the inference engine and the 
context storage and prioritization mechanisms of the black- 
board allow progress to be made in troubleshooting one 
problem while progress on another problem is impeded. In 
addition, the prioritization mechanism allows a new and 
more important problem to take precedence over a less im- 
portant problem. This is important to avoid investigating 
small or petty problems while the potential for a disastrous 
problem exists. 

Finally, forward and backward chaining are strategically 
applied to create the observe, hypothesize, and prove behav- 
iors. Forward chaining rules inform the blackboard that cer- 
tain information can be used as soon as it becomes avail- 
able. This sets up the measurements to be made during the 
Observation stage. When the information becomes available, 
the rule decides if a problem might exist. If so, a request to 
investigate the problem is created. This request represents 
upgrading the state of the problem to the hypothesized level. 
The blackboard then attempts to prove or disprove the prob- 
lem's existence, which generally triggers the execution of a 
backward chaining rule. The backward chaining rule will 
request additional data, which will generally lead to measure- 
ment execution and gathering of user input. As a result of 
this activity, a response is posted on the blackboard, and the 
fault's existence is proved or disproved. This process may 
happen for multiple problems during any given session and 
various certainties will be associated with each conclusion. 
Users can use these certainties and their own intuition to 



decide which problem to fix. Fig. 7 summarizes the activities 
that occur during this fault finding process. 

A Fault Finder Example 

The example in this section will show how the Fault Finder's 
expert system capability uses the observe, hypothesize, and 
prove paradigm to identify and solve a token ring network 
problem. 

A token ring LAN is configured as a logical ring. It consists 
of a set of computing devices, called stations, connected to 
the physical wire (see Fig. 8). The logical ring can operate at 
either 4 Mbytes/s or Hi Mbyles/s, and a station connected to 
the ring must be configured to the correct operating speed. 
The stations or spanning devices on the ring are connected 
to a mull istal ion access unit (MsAU or MAU). These MAUs 
are usually combined in racks in wiring closets. A MAU port 
contains a shorted connection (using a relay). When a Station 
is inserted into the ring the station applies a dc voltage to 
the media interface cable (or lobe) thai attaches the Station 
to the MAU. This voltage switches the relay in the MAU and 
serially connects the station into the ring without affecting 
the normal operation of the ring. 

The operation of a token ring network is composed of many 
functions. However, for this example only the beaconing 
function will be discussed. The beaconing function attempts 
to recover the ring from hard errors. Hard errors, such as a 
station inserting at the wrong network speed, usually occur 
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Fig. 7. Rules, activities, and data flows occurring during the fault 
finding process. 
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Fig. 8. Tli'- token ring layout for (he Fault Finder example 

within the station and permanently impair the stalion's 
ability to communicate on the ring. 

When a station detects an error on its nearest active path it 
sends a beacon frame containing the address or its upstream 
neighbor and the type of error encountered. This isolates 
the fault domain of the problem. The fault domain consists 
of the transmit path of the upstream neighbor station, the 
intervening cabling system (cables, MAUs. repeaters), and 
the receive pal It Of the Station. If I he upstream neighbor of 
the beaconing station copies eight of these frames it re- 
moves itself from I he ring and performs a self-test. If it 
passes the self-test the station will reinsert itself in the ting, 
and if ii fails, the station will stay off the ring. If the self-test 
does not resolve the problem, the beaconing station will 
remove itself from the ring and perform a self-test. If ii 
passes the self-test the station will itself reinsert in the ring, 
and if il fails, the siation will stay off the ring. If the beacon- 
ing Condition persists even after both stations have removed 
and reinserted, the condition is considered a permanent 
beaconing condition and will require manual intervention to 
resolve. 

A station inserting at the wrong network speed is a common 
problem when a new workstation is inslalled on a loken ring 
LAN. Specifically, a station inserting at ihe wrong network 
speed occurs when the network interface card is not config- 
ured properly for the network. The following scenario de- 
scribes how Ihe Fault Finder is able to troubleshoot this 
problem. 

The scenario begins when a network manager is selling up a 
new Novell workstation on a token ring network and while 
attempting lo attach to the server via the Novell netx com- 
mand, Ihe following error message is displayed on Ihe 
workstation: 

"A File Server could not be found." 

This message does not necessarily poinl the network man- 
ager in Ihe proper direction to solve Ihe problem and may in 
Ead misdirect Ihe manager. 

Fin ihis example, three mies and supporting predicates will 

be used from Ihe knowledge base These rules include the 
"inserting al Ihe wrong speed" rule given earlier, and one rule 
each for broken 0T Shorted Iransmil or receive wires. The 
following code shows a portion of the rule for the broken or 



shorted receiver wire problem. The rule for broken or 
shorted transmit wire is the same except thai the word 
transmit is used instead of receive. 

; Broken/Shorted Receiver Problem 

.Problem description 

problem! 

namel BrokenShortedRxProblem I 

nlsNamel 'Broken'.Shorted Receiver" I 

evemType' »FaultEverrt I 

frequencyl 50 I 

severityl 50 ) 

definition! The network interface card's receiver is bad, the receiver 
minus lead is broken, or the receiver pair is shorted 
together." ) 

solution! 'Run a Network Advisor Lobe test on the lobe wire of the 
specified station. This determines if the problem is the 
wire or the station itself If the lobe test passes, replace 
the network interface card and reinsert the station. '| 
hypoText! 'Station %?%address% may have a broken\shorted receiver. ' I 
concTextl 'Station %?%address% %+%has%%-%does not have% a 
broken receive minus lead or shorted receive pair. ' I 



Forward Chaining Rule 
hypothesize! 

name! hBrokenShortedRx I 

cost! 50 I 

confidence! 90 I 

explanation! 'If monitor contention is not resolved Itimes out) and 
the ring station enters beacon-transmit mode and transmits 
a beacon MAC frame, then it is possible to have a broken 
or shorted receive pair.' I 

logicText! 'BrokenShortedRxProblem! ?address ?addressNAUN | :- 



.Backward Chaining Rule 
backward! 

namel cBrokenShortedRx ) 

cost! 50 I 

confidencel 90 I 

explanation) 'The beaconing station will remain in beacon transmit 
mode until the signal is restored by the removal ol the 
station with the broken/shorted receive pair 
through the beacon-transmit auto removal test. This removal 
is verified by running a Station Adapter Status measurement 
to determine if the ring station with the broken/shorted 
receive pair has actually been removed.' I 

logicText! 'BrokenShortedRxProbleml Vaddress ?addressNAUN ) :- 



When Ihe Fault Finder begins executing, Ihe forward chain- 
ing rules invoke measurements to monitor (observe) Ihe 
network. The token ring commentator is an example of a 
monilor measurement. The loken ring commenlalor pro- 
vides a high-level abstraction of significant protocol events. 
Significant protocol events are defined as preludes to net- 
work performance degradation or nelwork failure. The lo- 
ken ring commentator allows the nelwork Iroubleshooter lo 
identify network problems without sifting through several 
pages of protocol decodes. 
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The following code shows a portion of the module for 
beaconing events, which are repotted to the token ring com- 
mentator when a network card inserts in I he network al the 
wrong speed. 

■«•••■••••••••••••••••»••••«■•«•••■*•••»*•**»*••*«*•••••«•••«••••• 

: Token Ring Network Events 

event! 

name! beaconMacFramesMomtor I 
nlsNamel 'Beacon' ) 
eventTypel ^ProtocolEvent ) 
frequency! 50 I 
severity! 50 I 

definition! 'A Beacon MAC Frame is transmitted if a station detects the 
expiration of the claim token timer during the monitor 
contention process. The station will broadcast a Beacon MAC 
frame isolating the domain to itself and its upstream 
neighbor ' I 

solution! " I 

hypoText! 'Monitor for Beacon MAC Frames ' I 
concTextl '%+%Station %%?+%address%%+% transmitted a beacon 
MAC frame %%-%No beacon MAC frames encountered. % ' I 
parameters! 

[ useBaselines 'string 'hypothesis " " ) 

I address ^string 'conclusion " " | 

[ addressNAUN 'string 'conclusion " " 1 



event! 

name! beaconingMonitor ) 
nlsNamel 'Beaconing' ) 
eventTypel #ProtocolEvent ) 
frequency! 50 I 
seventy! 50 I 

definition! 'The ring is considered beaconing if a station has transmitted 

8 consecutive Beacon MAC Frames ' I 
solution! " ) 

hypoText! 'Monitor for the Ring Beaconing ' ) 
concText! '%+%Station %%?+%address%%+% is beaconing station 
%%?+%addressNAUN%%-%The ring is not beaconing%. ' ) 
parameters! 



event! 

name! streamingBeaconsMonitor I 
nlsNamel 'Streaming Beacons' I 
eventTypel 'ProtocolEvent I 
frequency! 50 ) 
severity! 50 I 

definition! 'The ring station has been transmitting Beacon MAC frames.' ) 
solution! " I 

hypoTextl 'Check for the Ring Streaming Beacons ' I 

concTextl '%»%Station %%?»%address%%+% is streaming beacons at 

station %%?+%addressNAUN%%-%The ring is not streaming 

beacons%. ' ) 
parameters! 



event! 

name! newActiveMonitor I 
nlsNamel 'New Active Monitor' I 
eventTypel 'ProtocolEvent ) 
frequency! 50 I 



severity! 50 I 

definition! 'The new active monitor indicates the ring has recovered and 

is proceeding with normal operation.' | 
solution! " I 

hypoTextl 'Check for Ring Recovery ' ) 

concTextl '%+%New active monitor is station %%?+%address%%~%No 

new active monitor MAC frames encountered%. ' ) 
parameters! 



The rules are Ihen blocked pending measurement results, 
which satisfy lite rules' preconditions. < )nce the results are 
received they are posted on the blackboard A network in- 
terface card attempting to attach to a token ring network at 
the wrong network speed will cause a temporary beaconing 
condition on the ring. The token ring commentator measure 
inenl will identify beaconing on the ring and abstract I he 
beaconing condition into four different stages. The first 
stage, beacon, identifies that beaconing has been initiated 
on the ring. The second stage, beaconing, indicates that bea- 
coning has occurred long enough for the upstream siation to 
remove and perform a self-lest. The third stage, streaming 
beacons, indicates that beaconing has occurred long enough 
for the beaconing station lo remove and perform its own 
Self-test. The fourth stage, catastrophic, indicates a perma- 
nent beaconing condition. This particular beaconing condi- 
tion causes the upstream station and the beaconing siation 
to remove themselves from the ring. 

The token ring commentator measurement observes the 
first three stages of beaconing and posts the observations to 
the blackboard. The observations are displayed in the Faull 
Finder's Observations Hie shown in Fig. '1. Following I he bea- 
coning condition, the token ring commentator measurement 
also observes that a new active monitor is elected. This ob- 
servalion is used by the Faull Finder lo conclude thai the 
beaconing condition was temporary and that the ring has 
recovered. Since I he observations posted on I he blackboard 
satisfy i he preconditions specified for the three rules men- 
tioned earlier (broken/shorted transmit wire, broken/shorted 
receive wire, and inserting at wrong network speed), the 
problems can lie hypothesized. 

The problems hypothesized by the Faull Finder are a result 
of inferencing through Che antecedent pail of the rules. The 
possible problems are displayed on the Faull Finder's Possible 
Faults tile to show the user the current problems the Faull 
Finder is investigating (see Fig. 2). This feature is provided 
because the Faull Finder may have enough information to 
hypothesize a problem, but mighl nol be able lo prove thai 
the problem exists. This may occur because: 

• The Faull Finder cannot obtain the required information 
through measurements 

• The Faull Finder cannot obtain the required information 
from the user 

• The knowledge base does nol have the ability to prove I or 
disprove) the problem. 

The hypothesized problems are prioritized to allow a more 
important problem to take precedence Over a less important 
problem. Therefore, the Fault Finder will investigate the 
excessive ring length problem first because this problem 
could potentially effect the entire network while the other 
problems are niosi likely localized lo a single user. 
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The Fault Finder is able to obtain information on its own 
about the state of the network to prove ( or disprove) hy- 
pothesized problems. This is performed by the rules' re- 
questing information (via the inference engine) from the 
blackboard. The blackboard requests the data from the 
appropriate measurement modules and the results of the 
measurements are posted on the blackboard to allow the 
inference engine to continue and eventually prove (or 
disprove) the hypothesized problem 

In this example the hypothesized problems (broken transmit 
wire, broken receiver wire, or inserted at the wrong speed ) 
are proved (or disproved) by determining which device (if 
any) was beaconed off the ring as a result of the problem. 
This is determined by transmitting a token ring adapter sta- 
tus MAC frame to the suspected devices. The addressing 
information to determine which devices to query is taken 
from the observations made during the temporary beacon- 
ing condition. The rules will execute and configure the 
adapter status measurement to obtain the required status 
information from the device. The response or lack of a re- 
sponse from the adapter status measurement will be posted 
on the blackboard and used for further inferencing. In this 
particular example, neither of the devices was permanently 
removed from the token ring network. Therefore, the Fault 
Finder will conclude i licit there was not a broken transmitter 
wire or a broken receiver wire, but that a station with the 
wrong speed was inserted between the specified upstream 
and downstream stations. Notice for this particular problem 
the confidence level is indicated as [High] as shown in Fig. 2. 

When the Fault Finder discovers a problem on the network, 
the user is notified. This notification provides the user with 
information about the problem, a definition of the problem, 
and the reasoning and required actions to solve the problem 
This information is provided in the Fault Finder's explanation 
facility shown in Fig. 4. For a station inserting at the wrong 
speed, the required actions tell the user to change the set- 
ting on the network interface card, and provide an example 
of how to perform this task on an IBM Adapter II network 
interface card. 

This problem (inserting at the wrong network speed) fits 
well into the observe, hypothesize, and prove paradigm. The 



Fault Finder can observe or passively monitor the network 
for significant events to hypothesize possible problems. The 
real strength of the Fault Finder, however, is its ability to run 
instrument measurements automatically, to obtain status 
information from different network devices, and to prove 
that a problem exists. 

Conclusion 

Protocol analyzers provide powerful measurement capabil- 
ity that allows experienced LAN troubleshooters to solve 
many network problems. The Fault Finder provides the next 
generation in LAN troubleshooting tools. It automates the 
process of troubleshooting, allowing network managers to 
focus their efforts on those problems requiring human atten- 
tion. It incorporates the knowledge of expert t roubleshoot- 
ers into its rule base, allowing network managers to take 
advantage of a powerful problem solv ing instrument. Finally, 
the Fault Finder uses the same troubleshooting mode] as 
expert troubleshooters — observe, hypothesize, prove. 
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The User Interface for the HP 4980 
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A PC-based, object-oriented software architecture forms the underpinning 
for the HP 4980 Network Advisor's user interface. 



by Thomas A. Doumas 



Tin' III' 4! i.si i Network Advisor protocol analyzer's user inter- 
face provides L\N trotlbleshOOters with a clear, concise, and 
consistent presentation of measurement results. The user 
interface is built on a graphical, window-based system. Tlie 
user inleracls with a number of system windows lo access 
and control the features of the instrument. This interaction 
is through pull-down mentis, pushbuttons, list boxes, and 
dialog boxes associated with specific features. Support for 
servicing these user interactions is provided by a layer of 
soli ware called Ihe measurement architecture. The measure- 
ment architecture software and other system software are 
collectively called the general-purpose environment. The 
general-purpose environment software is written in the 
Object-Oriented Smalltalk language and runs on a PC. 

Working in consort with the general-purpose environment is 
another environment called the analysis and real-time (ART) 
emironmenl, which runs on a RISC-based hardware platform 
and provides the services for interfacing to the Network 
Advisor's front panel and the network under test A high-level 
view of the general-purpose and ART environments is shown 
in Fig. I, The ART environment is described in detail in the 
article on page 29. 

The following features are provided through the Network 
Advisor user interface: 
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• Simultaneous execution of measurements. The user can 
execute multiple measurements simultaneously. For exam- 
ple, users can stall a traffic generation measurement lo 
produce a specific network load and simultaneously 
monitor Ihe frames with protocol decodes and statistics 
measurements. 

• Graphical display. The Network Advisor user interface is 
enhanced by a graphical display. This Id-color, VGA display 
system prov ides a platform for displaying statistical infor- 
mation with presentation tools such as gauges, graphs, and 
liar charts. The network statistics measurement provides Ihe 
user with line graphs correlating multiple network parame- 
ters and gauges thai change color to indicate threshold 
events. 

• Consistency across measurements. All Network Advisor 
measurements are controlled with a common user interface. 
The user executes, configures, pauses, and stops all measure- 
ments with the same mouse clicks or keystrokes. Each mea- 
suremenl has a set of standard menu items for controlling 
these common features. 

• iser-definablc measurement presentation. The Network 
Adv isor presents Ihe measurement display by grouping the 
measurements into categories and subcategories. The stan- 
dard set of categories is first indexed by protocol stack* and 
then by measurement type (e.g.. statistics, timing, perfor- 
mance, etc. ). I 'sere can create their own categories and sub- 
categories containing their choice of measurements. This 
feature allows Ihe Network Advisor measurement selection 
window lo be customized for specific tasks. Since measure- 
ments can appear in multiple categories, new categories do 
not interfere with existing categories. 

• ( Inline help system. The Network Advisor software includes 
an online help system. The help system provides help on the 
QSC of Network Advisor features and help on specific data 
communications topics such as network protocols. 

Measurement Organization 

The Network Advisor presents the user with functionality 
oriented around the measurements on the network. Some 
examples of measurements include individual protocol de- 
codes, protocol stack decodes, traffic generation, network 



" A protocol sue* <s a group ot protocols that woi* together to provide a service lor network 
communication, and represents one possible choice ol protocols to' the seven layers ot the 
ISO OSI Helerence Model. For example. Hie ARPA stack delmes the protocols FTP. SMTP 
and telnet lor the application layer, TCP lor the transport layer, IP Ini the netwoik layer, and 
various protocols le g IEEE 802 3 anil 802.51 loi the data link layer, and leaves Ihe other 
layers undefined 
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performance summary statistics, automatic node discovery, 
and i he node generating the most errors. 

Traditional protocol analyzers provide access to their func- 
tionality by grouping features into a small number of prede- 
fined, fixed functional areas. For example, the IIP 4M72A LAN 
protocol anal.vzer groups functionality into the broad areas 
of decodes and statistics. The statistics functionality group 
is composed of a complex menu tree which gives the user 
access to fe a tu r e s as diverse as network |*erfonnancc stativ 
tics, connection matrices, and traffic generation. This menu 
tree presents the user with a variety of parameterization 
menus along the way. For example, the decodes functional- 
ity group presents the user with parameterization menus for 
selecting protocols, protocol layers, and display formats. 

The Network Advisors functionality is accessed through 
measurements. Each measurement is self-contained and has 
a set of configurable parameters that are specific to that 
measurement All measurements use the same user inter- 
face style for parameterization. The presentation of the mea- 
surements is controlled by the categories and subcategories 
that act as view filters. If the standard categories are not 
intuitive or useful for a particular situation, the user can 
create custom categories. 

This Network Advisor measurement organization provides 
the user with presentation functionality. Users can select the 
measurement needed without distractions from unrelated 
data. This is an Improvement over the collections of func- 
tionality in fixed pieces and the different user interfaces 
provided in traditional protocol analyzers. Fig. 2 depicts this 
difference in instrument organization. The upper portion of 
the figure depicts the Network Advisor concept and the 
lower portion depicts traditional instrument organization. 



General-Purpose Env ironment 

The software architecture for the general-purpose environ- 
ment is shown in Fig. 3. 

The main areas in the general-purpose software environment 
include: 

• Applications. These are the modules that provide features 
such as protocol decodes and statistics to the user and 
handle the displays and input from ihe user. 

• Frameworks. These are groups of classes that provide the 
foundation on which many of the user interface features are 
built. 

• Measurement Architecture. This is a set of global objects 
and classes that control shared resources and provide access 
to system functions. Shared resources include the hardware 
in the ART environment used to capture and hold data 
coming from the network under test. 

The software in the general-purpose environment is Imple- 
mented in the object-oriented Smalltalk language (see 
"Object-Oriented Design and Smalltalk" on page 24 ). 

User Interface Frameworks 

The Network Advisor user interface is built using multiple 
layers of frameworks. A framework is a group of classes 
that implement commonly used features such as printing, 
window system control, and paging and searching through 
data. A framework is generally used without modification by 
the layer of software above it. In some cases Ihe framework 
classes are subclassed for slight behavior modifications. 
Classes implemented at higher layers of the system do not 
"tunnel" through lower layers to access layers below their 
adjacent layer. This rule enhances the maintainability of the 
system. 
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Generic Application Framework (GAFW). The core system 
services of the Network Advisor are provided by a group 
of classes called (he generic applicalion framework. These 
classes implement the windowing system, ART inleiface, 
error handling, and so on. 

Specific Application Frameworks. The specific application 
frameworks provide a sel of classes to implement a class of 
measurements that have common features. The decode 
framework is a specific application framework upon which 
all the protocol decode measurements are huilt. This frame- 
work is different from the others because it supports a post- 
processing mode of operation. In addition, the decode 
framewor k provides a data throttling protocol* for run-lime 
decode displays thai are not required to maintain real-time 
display of received frames. The statistics framework, which 
is another specific applicalion framework, integrates multi- 
ple statistical measurements into a single composite mea- 
surement. It provides different ways of showing statistical 
data such as generic graphs, gauges, pie charts, and bar 
charts. It also provides configuration capability for each 
component measurement . 

Canned Test Framework. The canned test framework supports 
all of the canned tesls such as ARP,** ping, traffic generation, 
protocol commentators, and active station list. This frame- 
work focuses on programmatic control of the front-end data 
transmission interface and real-time display of results. 

Measurement Architecture 

The measurement architecture is a software platform that 
defines and implements a set of standard features and inlet - 
faces to system functions. These standard features and in- 
terfaces are implemented as global objects and thus are 
available to all measurement objects in the Network Advi- 
sor. Software dev elopers can use the classes of objects in 
the measurement architecture as they are. or modify their 
behavior With subclassing. The objects in the measurement 
architecture provide the classes to create the following user 
interface features. 

' A protocol in which the decode! sends a message iq trie ART environment to retneve the ne« 
eight frames of data 

' ARP (address resolution protocol) is used to find the physical address for a specific IP address 
in an ARPA protocol stack 



Object-Oriented Design and Smalltalk 

Objett-anented designs are based on the data that is present In the system The 
object-oriented model defines objects that encapsulate data and provide all de- 
fined operations Imethodsl that act on the data The entire system is modularized 
on the basis of the data structures. This is in contrast to procedural designs, which 
focus on algorithms and features The main benefit of the object-oriented approach 
is that the data provides more stability over time than algorithms because only the 
methods m the object can modify data, whereas with procedural designs, data 
structure changes and global access to data affect the stability of data. 

The major elements of the object-oriented model are abstraction, encapsulation, 
hierarchy, and modularity. Abstraction is defined as the description of a system 
that focuses on the details that ate significant while hiding the details that ate not 
significant Abstraction describes the external behavior of the object or system 
The concept of encapsulation means that the data structures of an object are 
accessed only through a publicly defined interface to the object and that the 
implementation details of the object are hidden. This gives the programmer the 
freedom to reimplement the object for improving performance or repairing defects 
without worrying that some user of the object is dependent on the specific data 
structure or the implementation of the methods that operate on the data The 
hierarchy of the object-oriented design is an ordering of the abstractions that define 
the system. In Smalltalk, the class hierarchy defines which classes can inherit 
functionality. For example, the class Dictionary inherits from the class Collection 
Modularity refers to aostractions grouped into discrete units. The modules should 
be loosely coupled so that changes in one module will not require modification m 
Dthers. 

In Smalltalk, abstractions ate defined in classes A class contains data and methods 
that operate on the data A program is built by creating instances of the classes 
and tying the instances together to create the desired solution 

To implement the user interface and the other classes in the general-purpose 
environment, we used SmallTalk/V286 from Dignalk Inc.. and a development 
environment called Envy/Developer from Object Technology Iniernational. Envy/ 
Develooer provides a network-based (Novell Netware) team programming environ- 
ment with tools for tasks such as source code control, revision control, debugging, 
and software production. 
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Features Selection. The user interface measurements window- 
presents the user with all of the available measurements. 

The menu items in the measurements window give the user 
the ability to open a measurement to run. to configure a mea- 
surement, to stop all measurements, and to run multiple mea- 
surements In addition to measurement control, the user can 
import measurements created on another Network Advisor. 

Measurement Configuration The Network Vi visor provides a 
set of user-modifiable parameters to control specific features 
of a measurement. These parameters can affect the presen- 
tation of data, and in some cases they can affect data trans- 
mitted on the network. I sers access the configurable param- 
eters of measurements with the Config menu item, which 
appears in each measurements window. The parameters are 
available to developers via a programmatic interface. 

User-Defined Measurements. The Network Advisor measure- 
ments call be cloned into new. user-defined measurements. 
This feature allows users to configure a measurement for a 
specific task and then create a new measurement using the 
same configuration. 

Display Management. All W iridovv objects use Hie displnv 
manager to display themselves when they are ready. The 
display manager keeps track of the location of all windows 
and suggests a size and placement for new windows. The 
display manager provides a similar function for the icon area. 

Measurement Control. \ll measurements ean be Started, 
stopped, or paused. In addition, all measurements can mod- 
ify the source of data (e.g., capture buffer or the network 
under test). 



Intermeasurement Communication. Because the results of one 
measurement might lx» of interest to another measurement, 
the measurement architecture defines a standard commu- 
nication path for intermeasurement communication. The 
requesting measurement only needs to register for results 
using a programmatic interface to receive the results from 
another measurement. 

Database The measurement architecture provides a data- 
base facility for the Network Advisor. Any me;isurement or 
system function can define and use the database facility. The 
node list brow ser is an example of database use. 

Interface to Analysis System. The ART and general-purpose 
environments interact through the interenvironmenl process 
communication fJEPC) channel. The [EPC channel manages 
bidirectional communication between the ART and general- 
purpose environments by buffering and dispatching mes- 
sages In both directions. All commands to the ART environ- 
ment are Forth si rings (see "The Forth Interpreter" below). 
The measurement architecture provides a high-level inter- 
face that allows programmers to build a Forth command 
and send it to the ART environment with a single message. 
The high-level DSPC interface supports simple commands 
(status response only), complex commands (multiple re- 
sponses), command response timeouts, error handling, anil 
priority commands. When a command is sent, an object in 
the general-purpose, environment is dynamically assigned an 
IEPC port number. This number identifies the sender of the 
Command and the receiver of the response. Communication 
with global objects is supported with fixed destination 
ports. 



The Forth Interpreter 

In the Network Advisor, the user interlace software on the PC communicates with 
a Forth interpreter in the analysis and real-time environment nn the pod * The 
Forth interpreter is used to configure and control the ART environment Commands 
such as stan and stop are sent to the ART environment as ASCII Forth strings 
These strings are passed to the Forth interpreter for execution 

Since the ART environment is wntten in C++ and the Forth interpreter is written in 
C. we needed a way to interface the Forth interpreter to the C++ code We decided 
that the best way to do this would he a call to a virtual function This would allow 
ob|ects to inherit Forth interlaces Since most obiects in the system are derived 
from a C++ class we defined as the root class, we decided that this was the place 
to detine the virtual function We also wanted to modify the Forth source code as 
little as possible 

We defined a global function caiiFonhFuncI) that takes two parameters; a pointer 
to an object and a pointer to the Forth stack This function is written in a C++ 
module and can call the virtual function It casts the object pointer to a root 
pointer and calls the virtual function lorthFunc(| passing the stack pointer By 
indexing the stack pointer, parameters can be passed between Forth and C++. 

By convention the first element ol the stack is used as an index to tell torthFuncll 
what function to perform If lonhFuncll does not implement the requested func- 
tion, it will call torthFuncll in the inherited class This call chaining creates an 
inherited Forth interface 

At system initialization, the ART environment stores a pumtei tu its global record 
in a Forth variable, This glnhal record is an obiect derived from the root class The 

' ApOdqa plug-in RWdUle for the Network Advisor that contains Ihe interface hardware and 
the real time analysis processot system 



torthFuncll for this class implements functions such as instantiating an applica- 
tion, returning pointers to other objects in the system, and configuring system 
parameters Supplying Forth with this one pointer allows it to make calls and gam 
access to the rest of the system 

Development Phase 

The Forth interpreter was also used in the development environment The ART 
environment and its applications were developed on workstations The front-end 
code was simulated using a disk tile Frames were read out of the file and passed 
to the applications The Forth interpreter was used to control the flow of these 
frames to the applications 

The Fo'lh word play" took the number on the top ol the stack as the numuer of 
frames to play to applications The Forth word step was defined to do a I play 
This allowed frames to be played into the ART environment to examine Ihe internal 
data structures between frames 

The Forth interpreter was also used as a debugging tool in the target environment 
A user interface to the Forth interpreter called Forth Window was created un the 
PC From this window. Forth commands could be sent to the Forth interpreter on 
the pod This allowed us to get and set system variables, dump parts ol memory to 
the debug port, query memory use, and so on 

Robert L Vixie 

Development Engineer 

Colorado Telecommunications Division 

" ttie piny command tells Ihe AflT envirnnmeni how many liames to process 
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Error Handling. Hie measurement architecture provides a 
variety of automatic error handling mechanisms. Errors gen- 
erated by the ART environment, applications, system func- 
tions, Smalltalk, and DOS an- all handled !>y these mecha- 
nisms. In many cases the Network Advisor can recover from 
an error and continue executing measurements. In other 
cases, the Network Advisor aborts itself and exits to DOS. In 
this case, data is saved in an ASCII file on disk so that it can 
be examined later to find the defect, 

Hardware Configuration. The analysis hardware is controlled 
by the analyzer setup interface. The user can modify the 
hardware configuration via the setup window. Measurement 
objects can access the same parameters through a program- 
malic interface. The hardware configuration parameters are 
categorized into two groups: network interface independent 
and network interface dependent. The network interface 
independent parameters include capture buffer Size, capture 
mode (circular or run until full), and capture filters (capture, 
exclude, or stop). The network interface dependent parame- 
ters include configuration commands for the IEEE 802.3 
Ethernet network interface card and the IEEE 802.5 network 
interface card. 

Node Lists. The node list feature allows the User to create 
and maintain node lists. The node lists are used by most 
measurements in the system to map physical network ad- 
dresses to mnemonics that are meaningful to the user. The 
node list can be created automatically with a measurement 
object that monitors the network traffic to discover nodes. A 
set of utilities converts node lists from a variety of formats 
into Network Advisor format. 



Event Log. The event log is a database of significant events 
that the Network Adv isor has observed. These events are 
grouped into the following categories: protocol, threshold, 
topology, fault, and Instrument 

Native Language Support (NLS). The Network Advisor soft- 
ware has built-in support for localization. The text displayed 
throughout the Network Advisor is provided by NLS dictio- 
naries. Through the use of NLS dictionaries, the text can be 
localized without modification of the code. 

PC Configuration. The Network Advisor software provides a 
set of configuration functions that are available to the user 
via the PC configuration window. These functions allow the 
display timeout to be set, measurements to stall automati- 
cally when the analyzer is invoked, and DIMS file operations 
to be carried out. 

Measurement Execution 

When the user requests via a menu selection to see certain 
measurement data, a number of objects are instantiated to 
perform the measurement, store the data, and display the 
results. Fig. 4 shows the system before a measurement object 
is instantiated and Fig. 5 shows the situation after a measure- 
ment object is instantiated. Some or all of the following 
events take place during measurement execution: 
• To execute a measurement, the user selects the measure- 
ment in the MeasurementSelectView window and then chooses 
the Run menu item from the MeasurementSelectView menu ( ! 
in Fig. 5). 
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■ After Run is selected, a Iine89age is sent to the Measurement- 
SelectModel indicating which measurement lo run ( 2 in Fig. 
•5). The MeasurementSelectModel holds a lisl of objects thai art 
as proxies for the ac tual measurement object. The proxy for 
a meastireineiii object holds the name of the class lo instan- 
tiate lor the specific measurement II also holds the name of 
a measurement file that contains the data for Ihe niea.Mire- 
menl. The proxy instantiates the appropriate class mid llien 
sends an initialize message to the instance C3 in Fig. 6), 
From here, the measurement object takes over and com 
pletes its own initialization, The measurement object reads 
ils database from disk mid creates Ihe MeasurementDataBase 
object ( i in Fig. 5). The MeasuremeniDataBase holds ihe 
definitions and current values of Ihe user configurable pa- 
ranuclei s for the measurement. In addition, the Measurement- 
DataBase contains the specification for Ihe view Chat Hie 
measurement object is lo build for displaying the measure- 
menl results. Willi Ihis information Ihe ResultView object is 
crealed ( & in Fig. 5). 
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• The ParmManager interacts with Ihe MeasurementDataBase to 
allow the user to configure the measurement ( e in Fig. 5), 
Examples of configurable parameters include the sample 
period for a statistics measurement, timestamp mode for a 
decode, or percent Utilization from a traffic generation 

measurement. The ParmManager objeci is instantiated 

when Ihe user requests Ihe configuration window for the 
measurement object. 

' A measurement objeci might require that the node lisi be 
loaded from the disk-based databases inlo memory. If this is 
Ihe case, then Ihe measurement object sends a message lo 
Ihe global node list object to accomplish this. 

i The measurement objeci might also post events lo ihe event 
log as part of ils start up sequence. An example would be Ihe 
lime Ihe measurement stalled. 

Some measurement objects automatically configure lo cer- 
tain hardware or art states. For example, the decode mea- 
surements will stall the data capture if Ihe daia source indi- 
cated in Analy/erSetup is Ihe network under lesl. If Ihe dala 
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source is Ihc capture buffer, then the decode measurements 
will request enough frames to fill the ResultView. The statistics 
measurements warn the user if the data source is not the 
network tinder test since statistics only execute in real time. 
After the measurement object is linked into the system and 
fully initialized, it will stall executing. To do this, the mea- 
surement object sends a message to AnalyzerSetup and re- 
quests that the front-ond measurement be Started ( 2 in Fig. 
5). AnalyzerSetup will get a unique handle (identifier) for the 
measurement and stall the data capture. AnalyzerSetup keeps 
track of which measurement objects have requested a stall 
measurement so that when the measurement objects re- 
quest a stop, the front end will not be stopped until all mea- 
surement objects have requested a slop. In this way multi- 
ple measurements can run and stop independently. 
Measurement objects can send messages to the AHT envi- 
ronment using the ServiceRequest object, which provides a 
high-level interface for sending Forth messages and receiv ing 
responses from the messages. 

When the user chooses to close a measurement, the mea- 
surement object breaks all of its references to system re- 
sources. This process includes removal of the ResultView 
object window from the window scheduler causing the win- 
dow to disappear. The Smalltalk memory manager will then 
be able to recover the newly available memory. 

Process Model 

The process model is an important part of the general- 
purpose environment because it supports the simultaneous 
execution of multiple measurements while still providing a 
responsive user interface (see F'ig. (>). Smalltalk supports 
separate processes with I heir own stacks of send messages. 
Processes all run within the same Smalltalk memory so they 
are more like threads than real processes with memory 
protection. The process scheduler is not time preemptive 
but rather selects a new process to run when an interrupt 
occurs or when the currently running process blocks, yields, 
or Brushes. 

The general-purpose environment runs two distinct pro- 
cesses. I )ne process is the user interface process and the 
other is the background process. The user interface process 
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Fig. 6. Process model and dispatcher. 

runs at a higher priority than the background process. The 
relative priorities are set this way so that the user interface 
can interrupt the background process and provide the user 
interface with good responsiveness. 

The user interface process processes all keyboard, mouse, 
and timer events. It also blocks on a keyboard semaphore 
until it is awakened by the keyboard interrupt service routine. 

The background process processes events that are gener- 
ated by the ART system. Examples of background events 
are statistics and decode data units, front-end control 
information, and analysis control information. 

Each process maintains a separate queue and dispatcher for 
storing the events generated for (hat process. This way, a 
large queue of background events cannot cause the user 
interface events not to be processed. This is the key to user 
interface responsiveness. 
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The Network Advisor Analysis and 
Real-Time Environment 



The user interface and protocol decode applications of the HP 4980 
Network Advisor use the services of a software platform that provides 
real-time protocol analysis and an interface to the network under test. 

by Sunil Bhat 



The analysis and real-lime (ART) environment of the IIP 
•1980 Series Network Advisor protocol analyzers is a soft- 
ware platform that has all the necessary services to support 
real-time network protocol analysis applications. To a lesser 
extent it also supports postanalysis of captured data. The 
ART environment is one of two major environments that 
represent the Network Advisors software architecture. The 
other environment is the general-purpose environment. 
The general-purpose environment provides support for the 
general-purpose programming of the Network Advisor. Spe- 
cifically, the general-purpose environment is responsible for 
the user interface, file management, and all other services 
that are essential at the user level. The general-purpose main- 
tains all persistent information like node lists and setup con- 
figurations, and treats the ART environment like a device. 
Both of these environments arc depicted in Fig. L 

Some aspects of the ART design were leveraged from the 
CONE 1 (common 081 network environment ) architecture, 
which provides a network-specific operating system for the 
IIP OSI Express c ard and an environment for implementing 
OS1 protocols. Specifically, the logical buffer services for 
encapsulation, segmentat ion, and reassembly of data were 
ported from the ("ONE implementation. 

At I he software level, (he general-purpose and ART environ- 
ments communicate with each other by an interenvirotinienl 
process Communication (IEPC) mechanism. At the hardware 
level, the ART environment executes on the AMD29000 Ris< ' 
based processor while the general-purpose environment 
executes on the Intel38(iSX-based processor and (hey com- 
municate via a shared memory module. The general -purpose 
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environment controls and configures the ART environment 
by sending messages via the IEPC" mechanism, and the 
ART environment transfers the results of its analysis to the 
general-purpose environment via the IKPC mechanism. 

Typically, any application on the Network Advisor has an 
analysis module that operates in the ART environment. This 
module does in real time all application-specific analysis 
based on relevant data from the network or network counts 
maintained by the hardware. There is also a corresponding 
module in the general-purpose environment that provides the 
user interface for the application. The applicai ion-specific 
user interface controls and configures its analysis module 
by commands sent across the IEPC. It also processes and 
displays the results sent by its analysis module to the user in 
some suitable format — graphical, tabular, or simple text. 
The Network Advisor allows multiple applications (also 
called measurements) to be active simultaneously. Therefore, 
at any given time there can be numerous applications active, 
each with its own analysis and user interface modules in the 
ART and general-purpose environments communicating 
across the IKPC. 

The general-pun io.se and ART environments constitute the 
toii-level logical entities of the Network Advisor's software 
architecture. The implementation of (he Network Advisor 
soil ware follows litis logical design very closely. The IEPC 
implementation is split between the general-purpose and lite 
ART environments. The general-purpose environment is 
written primarily in Smalltalk and the ART environment is 
almost enlirely written in C++. 

This article describes the architecture and high-level design 
issues Of the ART environment The user interface and more 
delails about the general-purpose environment are described 
in the article on page 22. 

ART Subsystems 

As shown in Kig. I, the ART environment consists of two 
subsystems: the processing unit and the acquisition unit. 
The processing unit contains hardware independent func- 
tions and lite acquisition unit encompasses all hardware- 
specific low-level functions. The processing unit is designed 
in he hardware independent mid can therefore be potted with 
relative ease onto Other hardware platforms, 

The acquisition unit is responsible for interfacing io the net 

work under lesl and all the relevant hardware counters and 
Miners. While connected to the network, the acquisition unil 
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captures real-time data and stores ii in a buffer called the 
captWV buffer. It also reports Status information and does 
all other hardware specific housekeeping. 

The processing unit is primarily responsible for real-time 
event processing. These events are typically data events 
stored in the capture buffer h\ I he acquisition unit. The 
events could also be commands senl from the general- 
purpose environment or events generated within the pro- 
cessing unit, The processing unit also supports event post- 
processing. This allows the user to capture a full buffer of 
data thai represents an interval of network activity, and I hen 
analyze it ill postprocessing mode. 

The Acquisition Unit 

The data flow of I he acquisition unit with respect to the rest 
of the system is shown in I"ig. 2. The acquisition unit ac- 
cesses the front-end hardware that interlaces to Che network 
under test. The fronl-end hardware transfers MA( -level 
frames from the network under test and stores them in tin* 
capture buffer along with a timestamp, length, and status 
information for each frame. These timestamps help protocol 
analysis modules correlate data with time. In the ART envi- 
ronment, frames that are stored in the c apture buffer typi- 
cally represent events. The introduction of a frame from the 
capture buffer to the processing unit is called a frame arrival 

MAC stands tor media access cannot, the lowest level ot the protocol stack Thus. MAC 
Irames are the Irames actually transmitted on !he physical network media 



event. Whenever an event is generated, it gets appended to 
the event buffer, which presents an event stream to the 
processing unit. 

The processing unit uses (he event data stream, control mes- 
sages from the general-purpose environment, and timer in- 
formation to produce two distinct data flows. The first data 
flow is the analysis information that is sent from the pro- 
cessing unit to the general-purpose environment via the 
1EPC. This information flow consists of the results from 
protocol analysis modules such as protocol decodes and 
network statistics executing in the ART environment. The 
results are packaged in an application independent form 
called analysis Herns. Analysis items are described in the 
article on page M. 

The other data How results from send requests generated by 
the general-purpose environment. This flow, which can be a 
single frame or a sequence of frames, provides stimulus to 
the network under lest. A traffic generator is a prime exam- 
ple of an application that can request entire sequences of 
frames to be transmitted repeatedly to create user-specified 
traffic on the network under lest. 

There is another distinct data path through the acquisition 
unit that is made up entirely of frames addressed to the Net- 
work Advisor. These frames are stored in the node card re- 
ceive buffer anil the acquisition unit reports them to the 
processing unit as node card arrival events. This data path. 
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along with the ability to send requests to the network, pro- 
vides the basic node card functionality that enables the pro- 
cessing unit to make the Network Advisor behave as a valid 
node on the network and not just a monitoring environment. 
This functionality is essential for supporting remote capabil- 
ities as well as interactive applications like ping and ARP. At 
the lowest level the front-end hardware provides the physi- 
cal interface to the network and is responsible for sending 
frames to and receiving frames from the network. 

Acquisition Unit Interface 

Access to the functionality of the acquisition unit is pro- 
vided by the acquisition unit interface which marks the 
boundary between the processing unit and the acquisition 
unit. The interactions across this interface are summarized 
in the following sections. 

Control and Configuration. The processing unit controls the 
acquisition unit. Among other things, it issues start and stop 
directives to initiate and terminate capture of data from the 
network under test. MAC-level frames are captured from the 
network in either continuous or autostop mode. In the con- 
tinuous mode the capture buffer is viewed as a circular 
buffer that wraps around until the processing unit issues a 
stop command. In the autostop mode data is captured until 
the capture buffer is full, which triggers an automatic stop. 
Based on user selection, the processing unit configures the 
acquisition unit to operate in one of these modes. Apart 
from direct control, the processing unit also configures 
acquisition-specific parameters like the size of the capture 
buffer. 

Most of the protocol information is available within the lead- 
ing portion of a MAC-level frame, which is made up of proto- 
col headers for each level of data encapsulation. The acqui- 
sition unit provides Ihe user, through the acquisition unit 
interface, with Ihe ability to specify the number of leading 
bytes of a frame thai should be stored in the capture buffer, 
In such a case, the frame is said lo be sliced to a specified 
length. This allows the user to store only the relevant portion 
of Ihe frame, which effectively increases the capacity of the 

capture buffer. 

Receive Data. The processing unit receives dala events from 
the acquisition unit. These events are MAC-level frames from 
the capture buffer. For each frame captured by Ihe acquisi- 
tion unit, an information header is added by the front-end 
hardware. This header information includes a t inieslamp, 
the received length of the frame, and other status informa- 
tion detected by the front-end hardware (e.g., CRC errors). 

Event Formation. The acquisition unit is responsible for the 
formation and reporting of all events or exceptions to the 
processing unit. As the frames gel stored in the capture 
buffer, the acquisition unit generates frame arrival events to 
the processing unit. Similarly, the acquisition unit generates 
a node card arrival event for each frame received that is 
addressed to the Network Advisor. It also reports the hard- 
ware counts (counter read event ) maintained by Ihe front- 
end hardware for statistical applications. Any change in the 
run mode of the acquisition unit is reported to the processing 
unit as a run-mode change event. 



Timestamping. The processing unit environment simulates 
time using discrete time information provided by the acqui- 
sition unit. All received data contains a timestamp. In the 
absence of data, periodic clock-tick events are sent to the 
processing unit. On the current hardware platform. Ihe pe- 
riod for this event is 100 milliseconds, which defines the 
worst-case resolution of time in the processing unit environ- 
ment. It should be noted that the hardware timer chips are 
initialized to the PC time ai bootup. This way all analysis is 
correlated with a time base. Also, all analysis items sent to 
the general-purpose environment have a timestamp for syn- 
chronization of the general-purpose and ART environments. 

Trapping and Filtering. The processing unit programs the ac- 
quisition unit trapping and filtering functionality using the 
set of filters and Boolean expressions provided by the hard- 
ware front-end. A filter can be specified to match a range of 
values for each of the first 127 bytes in a frame and the 
frame status byte in the frame header. A Boolean expression 
is the result of any logical combination of filters. A frame 
along with its hardware assigned header is stored in the cap- 
ture buffer only if it satisfies at least one Boolean expres- 
sion. The header provides a status field that reflects the re- 
sults of the Boolean expressions matched by the frame. For 
example, if we wanted to capture all frames sourced by 
node A and destined for node B as well as all broadcast traf- 
fic on the network, we would set two filters. We would spec- 
ify the source and destination address bytes in Ihe first filter 
to match A and B respectively, and set all remaining bytes to 
match any value (i.e., don't care setting). The second filter 
would have the destination address bytes set to all ones (for 
Ethernet) while the rest are don't cares. Finally, we would 
sel a Boolean expression to be the logical OR of the result of 
Ihe above specified filters. The Network Advisor also has 
the capability lo generate traps from software-matched 
Boolean expressions or external signals. Currently only soft- 
ware Iraps are implemented. The acquisition unit provides 
an indication to Ihe processing unit when a trap condition 
has occurred. 

Status. The acquisition unit provides status information to 
t he processing unit about items such as Ihe size of the un- 
processed capture buffer and ihe length of the send queue. 
This status information is used by the processing unit for its 
Internal activities such as flow control. 

Send Data. The acquisition unit provides services for the pro- 
cessing unit to send data frames lo Ihe network under test 
Each frame destined for Ihe network is defined by the pro- 
cessing unit as an object called a send object . Entire traffic 
scenarios can be described as a lisl of send objects. This 
enables the acquisition unit to support traffic generator 
applications. 

The Processing Unit 

Exception services constitute the core of the processing 
unit, which is an event-driven system. The basic control 
Structure Of the processing unit is shown in Fig. 3. The vari- 
ous entities in the processing unit communicate with each 
other by means of exceptions. In the context of Ihe process- 
ing unil. exceptions are events. Some exception types in the 
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system, like t he arrival ofa frame or Hie expiration of a sec- 
ond, are well-known. Applications can also dynamically allo- 
cate new exception types and generate them for their own 
use. Because of the event-driven nature of the processing 
unit, actions are triggered on the arrival of exceptions. 

Protocol analysis applications executing in the processing 
unit environment are essentially actions that exist Without 
any control of their own. These applications are called the 
exception handlers. Control passes to a particular exception 
handler when an exception occurs that il has shown inleresi 
in. This model is similar to environments thai handle window- 
ing applications. It is very effective in handling situations in 
which there are typically a number of events from different 
sources occurring asynchronously. 

Exception Dispatching. The central entities in the processing 
unit are the exception dispatcher and an exception queue, 
which stores events arriving from different sources. The 
dispatcher dequeues exceptions from the queue and invokes 
all interested handlers that have previously registered for 
the exception. The dispatcher, the exception queue, and all 
other associated dala structures constitute an operating 
region in I he processing unit because together these items 
can be viewed as a process. The processing unit was de- 
signed to support multiple regions with different priorities. 
However, for simplicity the current implementation has a 
single region. Therefore, there is a single dispatcher that 
services all exceptions received at the processing unit's 
periphery. The decision to implement a single region in the 
processing unit greatly simplified its implementation, and 
also improved its response time. 

To dispatch events to the appropriate handlers, the dispatch- 
er uses a table thai has an entry' for each type of exception. 
BaCh entry in this table contains a linked list of zero or more 
exception handler tokens. A handler token is basically a 
pointer to an exception handler function or routine. Any 
application in the processing unit registers for specific ex- 
ception types by enabling a handler loken. This has the effect 



of adding the handler loken to the handler lists for those 
exceptions the application is interested in. The handlers for 
a given exception are simply determined by indexing into 
the exception handler table using the exception token. 

Each exception in the exception Queue has a parameter loken 
associated with it that contains all exception-specific dala 
thai needs to be passed lo Ihe handlers when the exceplion 
is serviced. 

Event Synchronization. The dispatcher operaies in a synchro- 
nous fashion in that onlj one exception is processed to 
completion before Ihe next one is picked from the exception 
queue. The processing unit model is a cooperative nonlock- 
ing model. This means thai a handler cannoi be preempted 
before il completes processing. Therefore. Ihe burden is on 
all applications in Ihe processing unit to finish processing in 
a reasonable lime. 

The synchronous nature of Ihe processing unit has a number 
of advantages for protocol analysis applications, which 
include: 

1 In a synchronous system there are no race conditions 

between various modules. 
1 Since each event introduced into Ihe system is processed 

completely, there is no need lo reorder events based on 

timesiamp information. 
1 The correlation or analysis from different modules with 

respect to events and lime is greatly simplified. 

Timer Services. ( )nc of the centra] concepts with regard lo 
correlation of analysis from different modules, based on 
events, is Ihe notion of lime. The processing unit maintains 
I wo lime sources. One is called real time, which is driven by 
the periodic clock ticks from the hardware. On Ihe current 
hardware platform these lime licks are 100 milliseconds 
apart. This defines the resolution of Ihe real-time source. 
The other time source is line lime. This is time simulated by 
the processing unit using Ihe limestamps of the dala frames 
received in the capture buffer. The line time is advanced 
each time one of the frames is introduced to ihe processing 
unit as a frame arrival exception. In Ihe absence of frames, 
real lime is used to update line lime. 

Using these two sources of lime, the processing unit supports 
timers and the associated notion of timeout. Timers are rep- 
resented by the dala structure called timer token. Bach 
timet token has ils timeoul value and a handler loken for its 
handler function. The processing unit dispatches the timer 
token to its handler funclion when a timeout occurs. Any 
application module in the processing unit can create and use 
timer tokens. Standard timer functions like restarting, both 
in an absolute and a relative sense, and canceling a timer are 
all supported by the timer services of Ihe processing unit. 

For both real-lime and line-lime sources, all timer token 
expirations will occur chronologically. The processing unit 
guarantees thai a timer token with a timeout of N seconds 
will not expire before current lime plus N seconds, and no 
later than an event with a timestamp greater than current 
time plus N" seconds. Diuing run lime, line lime will I rack real 
time. In the case of postprocessing, line time is simulated 
using data frame limestamps alone. 
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Conclusion 

The ART environment was designed to be an optimized envi- 
ronment for supporting real-time protocol analyzer applica- 
tions. In addition to the basic ART environment, an extensive 
debugging and simulation environment was designed to sup- 
pon the development and preliminary testing of the process- 
ing unit on the HP-UX* operating system before integrating 
it with the acquisition unit running on the AMD29O0Q pro- 
cessor. This strategy allowed us to develop code in parallel 
with the development of the target hardware. It also reduced 
the integration effort required once the target hardware was 
available. 

The success of the ART environment design is reflected in 
the relative ease with which applications can be written 
using ART environment services. In fact, different applica- 
tions require different services, and as a result, the ART 
environment has been extended to provide frameworks for 
similar types of applications. The decode framework, which 
supports all protocol decodes and the canned test frame- 
work, which supports customized measurements for specific 
protocol analysis, are good examples of ART extensions. It 
should be noted that these frameworks in the ART environ- 
ment have corresponding frameworks in-the general-purpose 
environment. 

The processing unit was designed to be hardware indepen- 
dent. This decision enabled us to provide the Network Advi- 
sor with functionality for Ethernet, token ring, and FDD] 
media. Since the acquisition unit interface is an application 
program interface to the hardware-specific software, we 
need only provide an acquisition unit for the hardware we 



are interested in. The rest of the basic ART environment and 
its extensions remain the same. 
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Network Advisor Protocol Analysis: 
Decodes 



The decodes feature of the Network Advisor allows users to traverse from 
a high-level summary of protocol information to a bit-level interpretation 
of the protocol data. 

by Rona J. Prufer 



The decode portion of protocol analysis involves the recog- 
nition and interpretation of the syntax and semantics of the 
different types of network protocols. The HP 4980 Network 
Advisor is different from traditional protocol analyzers in 
that it attempts to interpret data from the network under 
test and provide answers to protocol problems, not .just 
reams of data. Two of the Network Advisor's key features 
are a flexible user interface and the number of decodes it 
can handle. 

Design and Development Considerations 

The considerations associated with designing the decode 
platform involved deciding how to: 

• Present information to the user 

• Divide protocol knowledge between the analysis and user 
interface environments 

• Make a contribution to industry-standard decode practice 

• Provide a productive environment for decode developers. 

Experience from previous products and user feedback an- 
swered many of the user presentation issues. The solution 



to dividing protocol knowledge between environments came 
from a definition of the division of responsibilities between 
the protocol analysis environment and the user interface 
environment. A contribution to decode practice was made by 
including knowledge of the network protocols and determin- 
ing and providing information to the user about a network's 
health. Finally, a productive environment was provided in 
which developers needed minimal system knowledge, allow- 
ing them to focus on protocol-specific issues. 

Presenting Information 

Presenting information to the user involved understanding 
the expertise of our potential customers. Experienced net- 
work managers know the protocols and most of the signifi- 
cant fields contained in the protocol fields. These users need 
to see a high-level view of the data and have the ability to 
focus on the specific problem when they determine that 
there is a problem. At the other end of the spectrum are nov- 
ice users who know little about protocol fields but need to 
have enough information to ensure that the network is 
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working. For these two very diverse users we found that 
there were three views of the protocol decode that would 
satisfy most requirements: summary view, detail \iew, and 
data view. 

Summary View. The summary view has several uses of the 
same format. The summary decode screen has one line per 
frame showing frame number, time, and three to four other 
significant fields (depending on the field sizes) This view 
can be used on an individual protocol or on a protocol stack. 
For example, Fig. 1 shows the summary decode for the in- 
ternet protocol (IP) in the DARPA* protocol stack. This 
summary shows the source and destination addresses in a 
dot-decimal format, the name of the next protocol layer, and 
the size of the data being passed to the next protocol layer. 
The summary View is also useful for seeing traffic on the 
network. By changing the format slightly, the user can see a 
network summary that shows the MAC** source and des- 
tination addresses along with a top-down list of the proto- 
cols contained in that frame ( Fig. 2). Another common use 
of a summary display is to show a stack-specific overview. 
For instance, the summary for the AppleTalk stack shows 
the source and destination MAC addresses and the Apple- 
Talk protocols contained in thai frame (Fig. 3). 

Detail View. The detail view is a full-sized window that 
shows one packet or protocol per display. The detail-view 
format has three columns. The first column lists the names 
of the fields in a packet, the second column contains the 
Current value in the field, and the third column describes the 
meaning of the field or the value in column two. In Fig. A, 
which shows a detail view of an IP packet, the first column 
shows an ordered list of (he fields that are in I he packet The 
first item on the lisl shows the version of Hie IP packet. 

Department of Defenso Advanced Research Proiects Agency 

MAC stands lor media access control, the lowest level ot the protocol stack thus MAC 
frames are the frames actually transmitted on the physical network media 



which according to the second column is 4. The second item 
shows that the internet header length field of the IP packet 
has the value 5, which indicates 32-b:t words ( column 
three). The precedence field has the value 000. . which cor- 
responds to routine precedence (as opposed to an urgent 
precedence). Following the ordered fields in the protocol is 
the derived information about the packet. For instance, 
there may be an indication about how much data a packet is 
passing up to the next layer, or information about the reas- 
sembly process or protocol-following process.*** The detail 
display can also be used to show the fields of an entire pro- 
tocol stack. For instance, it can show the Ethernet fields, 
the IP fields, and the TCP fields together in one display. 

Data View. The third view is of the data contained in a packet. 
Again, the flexibility exists to show all the bytes of the packet 
or just the bytes associated with a single layer. This display 
format lets the user see data in a format that may have more 
meaning. For instance, there may be users who want to see 
data in EBCDIC OT hexadecimal formats (Fig. 5). Another 
variation shows the entire packet of data with protocol 
headers separating the different protocol layers. 

Different Environments 

Tin' decode design is split between the I wo major functions 
of the instrument Displaying strings and values and format' 
ling are handled by the general-purpose environment, and 
protocol meaning is determined by a module in the analysis 
and real-time ( ART) environment. The general-purpose envi- 
ronment provides mechanisms for handling the Network 
Advisor's user interface and the ART environment provides 
services for Interfacing to the network and transporting data 
to and from I he general-purpose environment. For greater 

' ' Protocol tallowing is tracing the ddterenl slates a connection goes Ihrough In transfer 
information 
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flexibility all the incoming network data, after being inter- 
preted and pul in a special dala Structure, is senl from Ihe 
ART environmenl to the general-purpose environmenl. This 
allows Ihe user to select which formal is more useful and 
not have to wait for information to he processed again in Ihe 
ART environmenl. The services provided in the ART envi- 
ronmenl and Ihe relationship between Ihe ART and general- 
purpose environments are described in Ihe article on page 
29. The user Interface is described in Ihe article on page 22. 



The data Structure thai is passed between these two envi- 
ronments is called an analysis item. This structure was 
chosen because il allows many different protocols lo be 
described in one format An analysis item contains two or 
more analysis data unils (ADL's) as shown in Fig. (i. There 
is a one-to-one correspondence between an ADF and a 
protocol decode. 
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Each ADU contains three sections. The Drsi section is data 
for Ihe associated protocol layer, it is referred lo as the hex. 
The second seel ion is the syntax for Ihe fields in the proto- 
col. For instance, each field in Ihe protocol has a unique 
syntax record associated with It The lasl section is a seman- 
tics Section, Which contains additional information derived 
from analysis of Ihe protocol. 

The syntax section is further divided into a series of records. 
These records are patterned after the ASN.I encoding of a 
lag, a length, and a value field. 1 - Each field in the protocol 
is assigned a unique number (Ihe lag). In cases where several 
protocols share the same field, such as a destination address, 

Analysis Item 



AOU Top lot 
Protocol Stack) 
(User Data) 




Analysis Data Unit 



Syntax. 



Tag Olfset 
length Status/Error/Warning 



AOU Ethernot 



ADU: Bottom 
|ol Protocol 

Slack) 
(Media Data) 




AOU = Analysis Data Unit 

Fig. (>. \n analysis Item data structure 



this tag is shared so that it is always called Destination Address 
in the display of that field. The second field in the ADU is an 
offset field. It indicates where the bytes orbits exist in the 
hexadecimal field of Ihe protocol. If Ihe niosl-significanl bit 
is 1 then Ihe field is interpreted to be the number of hits, and 
if Ihe first bil is a I), il is the offset in bytes. The third field is 
the length of the protocol field. Again. Ihe most-significant 
bit indicates a bil or byte length. The last field is called the 
slat us/error/warning field. It is one of the two major con- 
tributions of Ihe decodes to Ihe Network Advisor. It tells Ihe 
user more information about a specific field. 

The semantics section of Ihe AIM ' has a more free-form for- 
mal. Il has a unique lag that describes Ihe information and 
the length Of thai information. Like all information passed 
between Ihe I wo environments, the dala in ihe semantic 
section niusl adhere to the long word* boundary rules. Ex- 
amples of Ihe information passed in ihe semantics seel ion 
include reassembly information, it-sequencing information, 
and protocol-following informal ion. 

Decode Development in the ART Environment 

The object -oriented C++ design of Ihe ART environment 
gives a decode designer four classes to work with. These 
include Ihe dala analysis class. Ihe module record registra- 

i class. Ihe path entiy class, ami the path SAT enirv 

class. A GNU-EMAGS editor function fills in Ihe class names 
and formats a module for simple default class protocol 
when a protocol module is lirsl checked out for design. This 
provides the decode designer with a foundation on which to 
add the features of a specific protocol. 

Data Analysis Class. The dala analysis class contains a func- 
tion called makeAdu lhal allocates and formats Ihe AIM" for a 

' A lonij wtiirt >s a loin-liylr) wnrrl 

' A SAP (service access point) is an addressable point at which protocol services are provided 
lm the real-higher protocol layer 
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particular protocol, li allocates memory space for the hex. 
syntax, awl semantic sections of the ADD. In most proto- 
cols, the fields are known and do not change. Only in the 
case of options or dependent fields are there extra fields 
thai need lo In- considered. Because of the large set of 
known fields, space (an be allocated and field values (lag, 
offset length, and slulus/crror/warning) can be defaulted. 
When the makeAdu routine is executing, it moves through 
each field in the frame data and analyzes it for significant 
facts. For instance, in the IP protocol, the version number is 
checked. If the version is not -I, the status/error/warning 
field of the version syntax record shows a number signifying 
a bad version. Another example is the IP internet header 
length. If this value is longer than the bytes available, an 
error is signaled in the status/error/warning field of the 
internet header length syntax record. 

The status/error/warning check can be as elaborate as the 
designer wants lo make it. In some protocols the difference 
between a good value and an unacceptable value is not 
straightforward. In other protocols there are no fields thai 
are open lo interpretation. For instance, in Novell's NetWare 
Core Protocol (NC'P) the completion code values are listed 
as having five valid values. An update to this specification 
for future releases of NCP may add more values, so our de- 
code cannot definitiv ely call invalid any other value used for 
a completion code. 

By using object inheritance, different features can be added 
to a decode in the semantic section of the ADU The devel- 
oper can inherit several functions into the date analysis 
class for conveying additional protocol information lothe 
user. An example is the dataSize record. This record indicates 
how much information is being passed up to the next layer 
in a protocol stack from the current layer. Another example 
is the calculation of a correct checksum. If the protocol has 
a bad checksum, it needs to be displayed along with the cor- 
rect value. This information can also be sent in a semantic 

record 

Module Record Registration Class. The module record regis- 
tration class allows the decode to be called from almost any 
place in the decode process, allowing a protocol to be en- 
capsulated. This situation is common in the case of the 
DARPA internet protocol. This IP can be called directly over 
Ethernet by patting the type field value of 0x0800 in the thir- 
teenth and fourteenth bytes of the Ethernet header. It can 
also be called from the SNAP protocol which is above the 
IEEE 802.3 and 802.2 protocols. The SNAP protocol maps 
the field value 0x0800 lo IP just as the type field of Ethernet 
does. Both of these protocol combinations call the same IP 
decode module. 

The module record registration class allows the decode 
writer lo specify the decode modules called from a particu- 
lar protocol. For example, in the IP module record registra- 
tion class, a value of •"> in the next protocol field maps lo the 
system calling the transport control protocol. Another exam- 
ple is 17, mapping to the user datagram protocol from the IP 
module record registration class. 

Path Entry Class. The path entry class joins the ADU items 
together to form a chain of ADl's collected into one analysis 
item. The data passed in the analysis item might contain an 



Ethernet ADU. an IP ADU, a transport layer ADU, and per- 
haps a file transfer protocol ADU. In addition, standard top 
and bottom ADl's are added to the package to take care of 
user data such as a file transfer (Ihe lop ADU) and media 
information (the bottom ADU). 

In addition to formatting the information sent to the general- 
purpose environment and eventually Ihe display, the path 
entry class also takes care of forming the paths in Ihe ART 
environment. These paths uniquely define address-specific 
mappings. For example, consider a protocol stack in which 
MAG address A is talking to MAC address B and the IP ad- 
dress for A is C and the IP address for B is D (see Fig. 7). In 
this stack C will be above A and D above B. The path entry- 
class will tie A lo B, A to C. B to D, and C to D so that one 
side of a protocol conversation can always see the state of 
the other side. 

Path SAP Entry Class. The path SAP entry class allows 
connection-oriented protocols to keep track of the two 
sides of a transaction and lo store additional informalion 
in a common area. A scratch space can be allocated lo keep 
track of the state of the connections, the sequence numbers, 
q and any other information that would help follow a connec- 
tion and share information between the two sides of the 
conversation. 

A strict layered approach to protocol analysis was chosen 
for the decode development model because it allows dynamic 
allocation of protocol analysis decodes and frees the devel- 
oper from the need lo depend on knowledge about any other 
protocol above or below a protocol module. For instance, 
the IP module knows that several different protocols can lie 
sent information via the next protocol field. However, be- 
cause of the layered approach in Ihe ART environment, the 
IP module does not have to know that any of these protocol 
decodes actually exists. The module will send the data to 
Ihe next layer, and if there is no decode for the data, the 
data automatically gets put into the top protocol module's 
hex field in the ADU. This indicates thai there are no more 
consumers for the data and signals the ART environment 
that an analysis item is complete and can be senl lo the 
general-purpose environment for display. The IP module is 
then ready to process the next frame. 
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Fig. 8. Components and data flows involved in decoding and 
displaying data in the general-purpose environment. 

Using a prototype template for these four classes and two 
very diverse protocols as the first ones to be developed in 
this environment, we were able to test some of the decodes. 
As more and more decodes were developed, improvements 
to the templates were made. For instance, a function call was 
added to set a bit indicating lo the general-purpose environ- 
ment that a frame contains an error. Also, subclasses were 
developed that are useful lo different protocol stacks. An 
example of this is a class for handling reassembly. This class 
is used in IP and the ISO network layer decode. 

To test decodes in the ART environment, the input to a 
decode was simulated using tools that take an input file de- 
scribing the scenario to be tested and provide a stream Input 
lo test the ART code on an IIP-l JX* operating system. This 
means that all the test cases a protocol can expect to see 
can be put into a Tile and tested as the code is developed. 

The ART environment is designed so that all protocol analy- 
sis can be done once in one place. This design allows the 
display modules to be concerned only with the presentation 
of data and not with any protocol-specific knowledge. 

Decodes in the General-Purpose Environment 

The decode modules in the general-purpose environment 
were designed around the three main methods of displaying 
information described earlier. These three displays allow the 
user to traverse from a high-level summary of information to 
the lowest bit-level inlerpretation. Since they arc relieved <>l 
any protocol analysis duties, the general-purpose decode 
modules concentrate on taking information from the analy- 
sis items from the ART environment and the Formal infor- 
mation from a database to provide the optimal display of 
Information to the user (see Fig. 8). 

Like the ART environment, the general-purpose environment 
was designed using an object-oriented approach. Because 
llieADI b consist ofthesame three sections, there is generic 
code in the general-purpose environment that parses each of 
the three sections. These parsing modules are optimized 
depending on the what the user is viewing. For instance, if 
the user Ls looking at a summary view with only one slack 
open, the parser can traverse (he analysis item pulling from 
each ADl' only the information needed for a summary 
view. This optimization leads to a Significant increase in 
the performance of the display system. 

For the decode developer, display formal informal ion is in- 
pul via a database file written in DBF (database format ). 
This ASCII file, which is usually wrillen near the end of (he 



decode development cycle, contains information about map- 
ping numbers contained in the ADL' to strings displayed in 
the decode windows. This file is parsed into Smalltalk 
Collection and Dictionary classes, which are used at run time in 
the general-purpose environment. This implementation has 
two very important advantages to the decode developer. 
First, no knowledge of Smalltalk is required to develop the 
decode modules. One less environment to learn helps to 
reduce tin- nonprotocol development time and fully uses the 
protocol analysis skills of the protocol export. The second 
advantage is that the decode developers are not required to 
do run-time debugging of the decode modules, This drasti- 
cally reduces the variety of hugs that occupy the protocol 
expert's time. 

The DBF file format has several sections. The first section is 
setup Information. This includes the name of the decode 
(e.g.. IP), the network media (e.g.. IEEE S02.3), and the 
names of the online help files that can be referenced. 

The second section in the DBF file contains data for map- 
ping the constants sent in the ADl "s lo the strings that ap- 
pear in the different protocol views. This mapping informa- 
i lion is split into four sections: mnemonics, errors, warnings, 
and status messages. There are some strings common to all 
these sections. For instance, if there is a checksum error, 
one common string to indicate this condition is included in 
the system errors file. In addition to mapping strings, the 
mnemonics section also has a provision for declaring the 
formal in which to display the value. Some common display 
formats are convertToOecimal. convertToBinary, convertToDotDecimal, 
convertToHex, and convertToAddress. Willi the convertToAddress 
format, user names are mapped to addresses and put into 
the database in place of network addresses. 

A significant contribution is the ability to display the proto- 
col fields in a manner that makes sense for each field. For 
instance, in die IP protocol the first field is (he version num- 
ber. Il is four bits long, and instead of showing the user the 
four bits, il is displayed in decimal as the Specification is 
written (a I is easier lo read llimi 01(1(1). Another example of 
ibis is also in the IP protocol. The precedence field is in the 
second byte of the protocol and is three bits long. To a user 
who is not familiar with this field, the values mean very 
little. However, to a Network Advisor user, (he value column 
shows (hat (he field is three bits long and specifies the three 
bits. In addition lo this, (he third column gives a high-level 
interpretation of these bits (Routine precedence in Fig. 4). 

The next section in the DBF file contains the strings for 
column headers for the Summary, detail, and data view 

windows. 

When the fields in Hie I >BF have been filled in, the DBF file 
is then put through a parse routine. This compilation is quite 
robust in terms of catching syntax errors and typing mistakes. 
The result is a file of type xxx mst. which is a measurement 
file used at run lime by the decode modules in the general- 
purpose environment lo display the decode information. 

The first pass through the development of the decodes in the 
general-purpose environment revealed many areas for opti- 
mization. Because the input to the decode modules is an 
ASCII file and the modules are developed with an object- 
oriented language, a second pass through the system was 
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done late in the development eyrie to find the common ele- 
ments among the protocols. For example, a number is now 
used to represent common field names, errors, and warn- 
ings. Also, the detail display uses every syntax record so 
there is no need to specify its formal in the ASCII file, and 
many of the same semantic records are used by protocols so 
a standard display method was developed for these records. 

The same testing approach used in the ART environment 
was used in the general-purpose environment. Files of ADUs 
for analysis items) were generated in the ART environment 
and transferred to a PC running the general-purpose envi- 
ronment. These files were then fed to the decode window as 
if it were running from data stored in the capture buffer in 
the ART environment. All of the test cases used to test the 
ART code were used to test the general-purpose portion of 
the product. In addition to testing in separate environments, 
test files were sent to art IIP 4972A protocol analyzer and put 
onto the IEKR 802.3 media for live capture by the hardware. 
The results from testing with the IIP 1972A were compared 
with results from previous tests to verify consistency of 
results and regression testing. 

The Results 

The general-purpose development effort for decodes was 
reduced to less than 20% of the total decode development 
lime because we used protocol templates, eliminated the 
need for our protocol expert to develop in Smalltalk, and 
used a robust parser that caught many of the syntax errors 
In the DBF file. Debugging time was also reduced because 
the general-purpose decode files are one step removed from 
the real-time processes. 

By dividing the decode implementation into two environ- 
ments and idenlifying conventions between common proto- 
col decode tasks, the development lime for new protocol 



decodes was significantly reduced. All major protocol slacks 
have been decoded and the embedded protocols have been 
accounted for automat ically. There is a great deal of code 
reuse between different protocol stacks because of the 
inherited functionality provided by using object-oriented 
environments. 

There are a few exceptions in which the strict vertical com 
mimical ion between protocols had to be subverted. For 
instance, in the SNAP decode, if the next protocol field indi- 
cates AppleTalk protocols, the lowest layer is examined to 
see if it is a token ring network or Ethernet A modification 
IS then made in Ihe ADU to send this (0 either a TokenTalk 
or an EtherTalk decode based on the lowest layer. Another 
example is in the Novell protocol stack in which a reply 
frame contains a frame number and a packet type for Ihe 
corresponding request frame. 
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Mechanical Design of the HP 4980 
Network Advisor 



The package design for the Network Advisor was guided by the electrical, 
mechanical, and ergonomic requirements of a PC-based protocol analyzer 



by Kenneth R. Krebs 



The HI' 4980 Network Advisor package consists of 31 
injection-molded parts. 15 sheet-metal parts, Hi cables, 
nine printed circuit boards, two custom-machined parts, a 
custom power supply, flexible and hard disk drives, a color 
or monochrome LCD ( liquid-crystal display), and numerous 
other custom and standard pails. Its hinged, fold-up. flat- 
panel display and fold-down keyboard are designed to make 
it easy to use the Network Advisor either on a desktop (see 
Fig. 1 on page 6) or in a floor-standing position (see Fig. 1), 
while providing maximum portability when closed. It has 
interchangeable network interface modules that mount to 
the underside of the instrument. The overall package mea- 
sures 6,9 inches high by 14.3 inches wide by 16.8 inches 
deep and weighs 25 pounds fully loaded. 




Fig. l. The Network Advisor in a Boor-standing position 



Design Decisions 

Mechanical design for the Network Advisor was driven by 
several major decisions made very early in the product defi- 
nition phase of the project. The first of these was to make 
the instrument DOS-compatible and. therefore. PC-based. 
Because of the dominance of the DOS operating system in 
the LAN testing market, our customers demanded DOS 
compatibility in our products. 

While we did not intend to market the Network Advisor as a 
PC that does protocol analysis, but rather as a protocol ana- 
lyzer with an embedded PC. we did feel that the ability to 
run standard PC applications (e.g.. word processors and 
spreadsheets) would be a marketing benefit. Therefore, we 
needed a full-screen. 80-coltimn display. Since the VGA stan- 
dard was emerging as the choice of the future, we chose it 
for our instrument. A second result of the DOS decision was 
the requirement for a full-function. full-Size PC keyboard 
and internal flexible and hard disk drives. 

A second decision (a result of the first design decision) 
was the need to be able to install ;it leasl one and prefer- 
ably two standard, off-the-shelf, full-length, low-profile 
PC cards. 

The third major decision was the choice of a flat-panel 
technology over a CRT. The VGA decision dictated a CUT 
too bulky and heavy to meet our portability requirements. 
ALso, CRTs have some manufacturing disadvantages we 
Wished to avoid (e.g., pincushioning, alignment, bigh v oltages, 
and shielding). We also felt thai the market perception of 
fiat panels as a leading-edge technology would be beneficial. 

We investigated several fiat-panel technologies including 
electroluminescent, gas plasma, and liquid-crystal. Electro- 
luminescent and plasma displays were cosily, had high powei 
dissipation and lacked sufficient grayscale shades. After 
investigating several types of LCD, we chose a cold-cathode, 
backlighted, film-compensated LCD as having the best com- 
bination of brightness, contrast ratio, cost, and weight, .lust 
before our tooling release. Sharp Inc. introduced a 10.4-ineh- 
diagonal, TFT (thin-film transistor) active matrix, color LCD, 
which is larger and thicker than the monochrome LCD we 
had chosen. After a redesign effort to accommodate the 
larger display, the display housing injection mold was de- 
signed with inserts to allow for both color and monochrome 

versions, 
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Because there are several different networking technologies 
(e.g., token ring network, Ethernet, fiber distributed data 
interface (FDDI)), our instruments need different hardware 
sets for data acquisition and analysis and different external 
connector types for connection to the network. In the past 
we accomplished this by offering different interface mod- 
ules (pods) cabled to the base instrument (mainframe). Con- 
sidering how to handle different network technologies led to 
our fourth major design decision which was to integrate the 
pods into the mainframe so thai nothing external would be 
required or would hang off the instrument and get in the 
way during operation. These integral pods needed to be easy 
to install and remove. The difference in networking technol- 
ogies also required that the network line and event status 
LEDs on the front panel (up to 12 pairs with each pair con- 
sisting of one red and one green LED) lie easy to relabel 
since different network types have different numbers and 
types of lines and different nomenclatures. 

Another important design constraint was the requirement 
that the user be able to operate the instrument conveniently 
on a desktop and on the floor. Frequently our customers 
need to make their network connections in a small control 



room, a closet, or around the back of a patch panel where 
tablet op space is unavailable. 

Since many of our customers are third-party network service 
providers who travel with the instrument to their customers' 
sites, the instrument had to be truly portable and rugged. 
This meant thai it had to lit under an airline seat and weigh 
less than 38 lb (we set a target of 20 lb and achieved 25 lb 
with a fully configured Instrument). This also meant that we 
needed a Carrying case not only for the instrument but also 
for appurtenances such as interface cables and different 
interface modules. 

Many of our customers are network managers who do not 
routinely move their instruments from place to place. There- 
fore, we wanted a Configuration that would work well with 
an external color monitor, preferably one that could support 
the monitor on lop of it so as to use as little desktop space 
as possible. 

Lastly, we wanted a package that made a true contribution 
to manufacturability by being very easy to assemble and ser- 
vice. Therefore, we wanted to eliminate as many fasteners 



Display Housing 




T 



Fig. 2. Display housing and other 
components for I lie color LCD 
panel. 
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and small parts as we could. We also wanted this package to 
be as flexible as possible for maximum longevity and reuse. 

Design Concept 

The design decisions described above resulted in the follow- 
ing implementations for the Network Advisor package. 

Display Housing. The choice of a VGA flat-panel display dic- 
tated a design concept in which the display rotated or other- 
wise moved into viewing position. To make it stationary on 
the front panel would have made the instrument too large or 
required an upright package similar to the HP integral porta- 
ble scientific computer — a design ill-suited for floor opera- 
lion or for use with an external monitor. Rotating the display 
up and back into position as is done with a laptop was 
equally unsuitable. Rotating the display up and forward puts 
ii in good viewing position above the keyboard for desktop 
operation, and rotating it a bit farther puts it in good posi- 
tion for floor-standing operation with the instrument stand- 
ing on its rear feet. The display housing unit has two pivot 
arms at its bottom corners (see Fig. 2). The right pivot arm 
carries the friction clutch that holds the display in any posi- 
tion. The left pivot arm routes and protects the display sig- 
nal and backlight cables. In addition, the left pivoi arm has a 
short, molded circular protrusion which acts as a shaft. This 
shaft gels captured between semicircular fealures molded 
into the front panel and a front-panel rear cover piece which, 
when the pieces are assembled together, form a beating (see 
Fig. This bearing captures the shaft" for rotational support 
of the left side of the display housing unit. In its folded-away 
position, the display resides In a recess molded into the 
plastic top chassis. 

Even in its folded-away position, the fronl of the display is 
exposed, and a cover piece is required to protect I he display 
during travel. This protective lid has side latches thai snap 
onto the top chassis. The side latches are pressed inward to 
release the lid. whereupon it is rotated up and back (see Fig. 
4). After the display is raised, the lid is again dosed and 



Fig. 4. The protective lid used to protect the display during travel 
Also shown is the location of the detachable pod assembly which 
snaps into the underside of the mainframe of the Network Advisor. 
The pod assembly is discussed later in this article. 

latched. The lid also acts as the platform to support an ex- 
ternal monitor when the display is left folded away (a user 
must software-select which display is on at any one time to 
keep the internal display from overheating when closed ). A 
large, polycarbonate label covers the underside of Ibis lid to 
hide the extensive ribbing needed for stiffness. 

Keyboard. The full-size keyboard is hinged onto the front 
panel where, in its closed and latched position, it protects 
itself and the front panel. It unlatches and rotates into posi- 
tion on two custom shoulder screws. Nylon-inserted lock 
mils captured in each end of the plastic keyboard housings 
keep the shoulder screws from backing out against the key- 
board rotation. A crescent spring washer sandwiched be- 
tween a Hat washer (to protect the plastic from galling) and 
the underside of each shoulder screw head provides friction 
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lo hold the keyboard in any posilicin for typing (sec- Fig. 5). 
Normally the keyboard is simply rotated until it rests on the 
desktop at a seven-degree angle for comfortable typing. 
When the instrument is standing vertically on its rear feel 
for floor operation, the keyboard rotates around to a slop so 
that it is in a comfortable position for typing while sitting in 
front of the instrument (see Fig. 1). While nol easily detach- 
able, the keyboard is removable in the event that a user 
wishes to use a standard 101-key keyboard instead of the 
one provided. An adapter cable is provided for this purpose. 

More than any other feature, the keyboard, folded in a verti- 
cal position when closed, determined the height of the 
Instrument The keyboard and the need for a full-length PC 
card determined the width of the instrument. The overall 
length was determined by the components inside the instru- 
ment, with consideration given to how (all the package stood 
in its floor-standing mode. 

Top and Bottom Chassis. The bottom Chassis acts as the 
foundation on which all other subassemblies rest (see Fig. 
fia). It measures inches high by 14 inches wide by 14.2 
inches long and is molded in a (i()0-lon press. To reduce the 
number of screws, many molded features act either as snap- 
fit receptacles or anchor's for other pails and assemblies. 
Major assemblies Stich as the front panel, handle, and rear 
panel drop vertically into molded grooves and are held in 
place until the installation of the top chassis captures and 
anchors them by I he addition of four screws. The top chas- 
sis (Fig. lib) is roughly the same size as the bottom and is 
molded in the same press. Tabs on the lop chassis male lo 
slots in the from panel and front-panel rear cover tO anc hor 
that assembly and provide good seam contact for F.MI 
suppression. 

Pods. The interchangeable interface modules (pods) house 
the data acquisition and analysis hardware and the connec- 
tors for I he physical interface to the network. A plastic 
molded housing forms the bottom section of the pod con- 
tainer. A pair of painted and screened sheet-metal covers are 
lap-joined together using flat head st rews, countersunk 
punched holes in one piece, and press-in floating fasteners 
in the other lo form the lop section of the pod container (see 
Fig. 7). This was done lo compensate for assembly tolerance 
stackup and to allow for easy assembly of different network 
connector types and combinations. The printed circuit 
boards mount to each other via board ! o-board connectors 
and snap-mount, press-in standoffs. The printed Circuit 
board subassembly then snap-mounts to press-in standoffs in 




Fig. 5. Keyboard connection to the front panel. 




Fig. 6. (a) The liotlmu chassis nfllit' Network Advisor, (h) The tup 
chassis of th« Network Advisor. 
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Metal Covers 



IEEE 802.5 
(Token Ring) Board 



IEEE 802.3 
lEihernell Board 






Main Pod Board 



(a| lb) 

Fig. 7. Pod assembly, (a) Tile three- main components of the pod ami how they go together i'b) The assembled pod. 



die sheet-metal covers. The whole assembly then screws to 
the plastic pod housing. 

An assembled pod mounts on the underside of the mainframe 
(see Fig. l) using four quarter-turn fasteners. The quarter-turn 
studs are captured, but float freely in the pod housing and 
male to receptacles that are ullrasonically installed in the 
bottom chassis. All of the standard PC signals are bused 
from the mainframe to the pod through a 140-pin connector 
pair which automatically male during pod installation. The 
pod cannot be installed incorrectly. The network interface 
connectors are mounted along the side <>f the pod, which 
puts them in easy reach for connection to the network, espe- 
cially in floor-standing operation. The exposed sheet metal 
front panels ofthc pod through which these connectors pro- 
trude are recessed in keep the connectors protected. How- 
ever. ltu"S configuration reduced the internal width available 
in the pod for printed circuit boards. A full-length, standard 
P< card was too long lo lit in Ibis width. Therefore, two 
plastic molded end caps were looled lo allow for the inclu- 
sion of the I'C card. In this case, the sheet tneial. no longer 
exposed, is reduced to a single, Hal. unpaintcd piece whic h 
helps retain the end caps and close up I he pod. The pod can 
accept either one full-length and one MAl-lcngth, low-profile 
I'C card, or our custom LAN data acquisition boards, but not 
both simultaneously. I5ecau.se we offer some products in the 
form of PC cards for use in customers' existing network 
Computers, these cards can also be put into pods for use in 
the Network Advisor. ( )ne example of this is the IIP 49"»7PC 
wide area network analyzer, which is on a PC card. With this 
feature, a customer can install an IIP l(l.">7P( ' into a pod to 
make ihe Network Advisor into a WAN analyzer. 



Bottom Feet. Along the hot I on i of the pod housing are molded 
two long rails that "join" the front and rear bottom feet 
molded Into Ihe bottom chassis. These rails are 0.5 mm 
shorter in heighi than the chassis bottom feet. This ensures 
that while the bottom feet are always Ihe ones to bear the 
weight of Ihe Instrument, they do not catch Ihe back of a 
user's leg when the instrument is carried by ils padded, 
flexible side handle. 

Rear Panel. The molded rear panel mounts the line filler/fuse 
module, the fan. and the external PC polls printed circuit 
board, which provides two serial ports, one parallel port, 
and one video port (see Fig. S). The area behind which the 
P( ' ports board mounts is formed using moid inserts lo allow 
easy changes in Ihe number and configuration of connectors 
(e.g., adding HP-IB or SCSI). A fan grill and cage are molded 
Into the panel so I hat the fan can be snapped into the panel 
without the use of fasteners. A molded-in feature acts to 
capture the RAM backup baltery in the bottom chassis when 
the rear panel is installed. All lext and graphics (connector 
labels, line information, safety warnings) are molded-in on 
mold inserts lo make Ihem easy to change or repair. Also, 
lext is indented in Ihe plastic (raised on Ihe inserts) and 
molded into shallow recesses to accept labels lo cover the 
lext if it becomes necessary (e.g., labels for different lan- 
guage versions). A long label was added to accept new 
warning and regulatory messages as they become necessary 

Tooling and Molding 

HP's Palo Alto Fabrical ion Center (PAFC) molds most of the 
Nelwork Advisor's plastic parts. Mobay's Bayhlend FR1 1 11 
polycarbonalc/ABS blend was chosen as Ihe basic material 
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Lino Fillet/Fuse 
Module 




Fi«. 8. Components attached to the rear panel of the Network Advisot, 

lor ils combination of strength, moldabilily, appearance, and 
price. Two parts, the display cover lid and I he display hous- 
ing rear- cover (both huge, thin pails), required FK1439, 
which has a higher percentage of ABS, for increased mold- 
abilily lo prevent warping and to reduce blush. Two small 
pans ( molded by a second vendor), the snap-on side feet 
and the snap-on rear mounting screw covers, use GE's Lexari 
020 straight polycarbonate. While we feared a noticeable 
gloss difference between the blended and straight materials, 
our fears were not realized and the match has been good. 
The snap-on display lid latches also use this material for 
strength reasons. They have a molded-in cantilever spring 
that provides I he force lo return them to their home posi- 
tions after unlatching; Straight polycarbonate with its higher 
allowable Strain rates and creep resistance was needed for 
these springs. The friction dutch arm bears the brunt of the 
display housing support and torque when moving I he dis- 
play. Fortius reason, it is molded in a 40% glass fiber filled 
polycarbonate for strength and stiffness. The keycaps are 
molded in polyester to allow sublimation priming of the 
three keycap legend colore. 

All external cosmetic surfaces are textured using an HP 
frosted grain III specified as 0.001 inch deep on typically 
2.5° draft.* Some surfaces, however, were designed with 
only 1.5° draft. On these surfaces, the texture is specified 
as 0.0005 inch deep to avoid possible ejection problems. 

" A draft is a slight angling of the vertical walls of an injection mold to allow the molded part to 
separate from the mold 



As mentioned previously, the display housing and display 
housing rear-cover molds were designed with I wo sets of 
inserts to accommodate the color or monochrome LCD dis- 
play. The color LCI) has the larger active area opening and 
requires different mounting boss height and location. 

The handle-mounting piece and the front-panel rear cover 

piece are about the same size and weight. As a result, they 
were put into a family mold lo save an both mold cost and 
part cosi. This later had the disadvantage of changing two 
pails when only one, the handle mount, needed its thickness 
reduced. Additional work was then needed on the front- 
panel rear cover lo compensate for the reduction in the 
mold separalion line 

During the lab prototyping phase, we soil -tooled the entire 
box using urethane molds for pails over 40 square inches 
and aluminum tools for the smaller pans (a process limita- 
tion). The vendor worked directly from UJES** translations 
of our 2D. undimensioned HP ME 10 drawings. The pans 
had molded-in color and texture bill were soft and capable 
only of limited structural and lemperaiure testing. The 
smaller parts, molded in aluminum lools, were molded in 
their proper ntaterials, which allowed thorough structural 
testing of these parts. While this process produced high- 
qualiiy parts lhal were very useful in our evaluation, the 
process was cosily and look much longer than the vendor 
estimated. 

With an all-plastic enclosure, we knew thai shielding tech- 
nology would become a critical factor. From the oulsel, we 
planned on vacuum-deposited aluminum for Ihis.job. This 
technology was available in very few places. Also, the size of 
some of our parts (requiring up to 000-ton presses) limited 
the molder selection greatly. However, one molder had up lo 
1000-ton presses and ihe ability to do vacuum deposition 
in-house. This vendor selection later proved to be unfortu- 
nate for two major reasons. First, they relied heavily on cul- 
ling cavities in the parent steel. Many of our parts have deep 
ribs and intricate features which, later experience would 
show, would have been more easily polished and Otherwise 
itined had they been formed using mold inserts. While more 
cosily up front, inserted molds would have saved us lime 
and money during the tool iryout and liming phase of our 
product development In some cases, attempts at changing 
the parent steel, especially polishing of deep ribs, caused 
mold damage that could not be fixed, leaving some parts 
permanently out of specification. In these cases, unfortunate 
and costly design changes were necessary. 

The second reason was thai we found out very late in the 
tool iryout phase lhal ihe molder could no longer supply us 
with molded parts. During Ihe ensuing turmoil we initialed 
OUT contingency plan of moving the molds to PAFC, which 
had recently installed a new 550-tOH press capable of mold- 
ing our larger parts. This transition would have been signifi- 
cantly more painful if our materials department had nol 
planned for it 

IGES llniiial Graphics Exchange Specification! is a file format that is used to describe models 
created with CAD programs 
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Environmental Testing 

The 2-to-3-um-thick vacuum-deposited aluminum coating 
proved to l>e an ineffective shielding technology with which 
we experienced flaking problems, especially during humid- 
ity testing. Our search for an alternative included nickel- 
based and copper-based paints, electroless copper plating, 
and zinc arc spraying (ZAS). Alter tests and evaluations of 
the controllability of the processes, we opted for ZAS. a ca- 
pability that PAFC had in-house. W hile this has proven to be 
more costly than vacuum-deposited aluminum, ii has al- 
lowed us to meet our targeted CISPR 11 s radiated emissions 
specification. Initially, because the silicon ZAS masking fix- 
tures are soft and flexible for easy cleaning, the force of the 
spray would sometimes blow the mask away from the part 
allowing zinc overspray to get on the Cosmetic surfaces. 
Reinforcing the masks brought the process under control. 

Many of our pari interfaces were designed with 2-to-3-um- 
thick aluminum coating in mind and therefore had very small 
clearances. The move to (MM):j-to4l.007-inch-thick zinc caused 
some clearances to become interferences. In some cases, 
this required tool modifications lo make pails thinner. For- 
tunately, in most cases this could be accomplished by simply 
shaving the core-side palling line and readjusting shuloffs if 
necessary. In other cases, costlier tool modification requir- 
ing welding and recutling was needed. However, in one case 
welding was unpractical and zinc had to be masked from 
affected areas. While shielding effectiveness was reduced, 
the ZAS process, coupled with oilier internal electrical and 
cabling modifications, gave us enough margin to pass the 
CISPR 11 specification. 

The package was tested to I he IIP class Bl shock and vibra- 
tion specification ll was tested in eloscd-up-lbr-l ravel, desk- 
lop (display up. keyboard down), and floor-standing config- 
urations in bold color and monochrome display versions. 
No unacceptable damage was sustained. 

Cooling of the package is prov ided by an 80-mm-square 
tubeaxial fan with a maximum airflow of 38 ft'Vmin. Ambient 
air Is drawn in al the rear Of the pod, across the pod elec- 
tronics, and up through the top oflhe pod in'o the bottom 
chassis. Once inside the mainframe, il joins air coming from 
I he base of the from panel, goes across the power supply 
and the PC system primed circuit board, and exhausts 
through the tear panel. ( )ur worst-case pod, dissipating ap- 
proximately 50 watts, experiences an air temperature rise of 
only Hi < '. The temperature rise in the mainframe is 12°C 
above the system board and lil ( ' above I he power supply. 

ComitG International Special ties Perturbations Railioeleclrio.ues (International Special 
Committee on Radio Interference) 



All of these temperatures remain well below what we can 
tolerate given the temperature limitations of the disk drives 
and the LCD. The maximum allowable ambient operating 
temperature of the hard disk drive and color LCD is 40°C. 
and that of the flexible disk drive and monochrome LCD is 
45 3 C. The minimum allowable storage temperature of either 
display is -25C. Therefore, the full HP class Bl temperature 
specification had to be waived in deference to these compo- 
nents. The monochrome LCD experiences extreme response 
sluggishness at very low temperatures and washes out at 
high temperatures (adjusting the contrast control does not 
help). The color LCD experiences no such performance or 
visual degradation at the temperature extremes. 

The supersoak and condensation portions of our humidity 
testing were not done because the LCDs and disk drives do 
not allow them. The polarizers on the LCDs cannot tolerate 
standing water for any length of time. However, we have an 
optical film applied lo both LCDs for anti-glare and protec- 
tion from scratching and chemical contamination, The other 
humidity testing done on the instrument presented no 
problems. 

WTtile our altitude testing indicated no problems, we learned 
a valuable lesson regarding altitude effects. The large label 
thai covers the ribbing on the underside of the display cover 
lid ent raps air in the dozens of hermetically sealed pockets 
it forms. When an instrument built at a 6000-foot altitude 
(like Colorado Springs) made its way CO sea level, these 
pockets collapsed a little causing an unacceptable dimpling 
effect in the label. As an interim remedy, we had to machine 
v ents into the top of one rib in each pocket to allow the 
pressure to equalize. Later, 122 pins were added to the mold 
lo provide these vents. 

ESD testing has shown no hard failures up to the 2. r >-kilovolt 
limit. 
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The Microwave Transition Analyzer: 
A New Instrument Architecture for 
Component and Signal Analysis 

The microwave transition analyzer brings time-domain analysis to RF and 
microwave component engineers. A very wide-bandwidth, dual-channel 
front end, a precisely uniform sampling interval, and powerful digital 
signal processing provide unprecedented measurement flexibility, 
including the ability to measure magnitude and phase transitions as fast 
as 25 picoseconds. 

by David J, Ballo and John A. Wendler 



As signal processing capabilities advance, modem micro- 
wave and radio frequency ( RF) systems are becoming more 
and more sophisticated. I'ulsed-RF signals, once used only 
for radar applications, are increasingly being used in com- 
munication systems as well. These signals routinely have 
complex modulation within the pulse, especially frequency 
and phase variations (see Fig. 1 ). Operating frequencies and 
bandwidths continue to increase, placing additional demands 
on the components of the systems. 

Engineers responsible for the design and testing of such 
components and systems often need to measure them under 
the same dynamic conditions as those in which they are 
used. For example, it may be necessary to measure a de- 
vice's response to phase coding or linear frequency chirp 
inside an RF pulse. 

Measurements with traditional frequency-domain instrumen- 
tation are often insufficient to characterize and understand 
fully the operation of components in dynamic signal environ- 
ments. Before the microwave transition analyzer introduced 
in Ibis article, no single instrument could handle the diverse 
range of measurements required for dynamic testing at micro- 
wave frequencies. In addition to the new measurements it 
makes, this analyzer can perform many of the measurements 
previously requiring the use of network, spectrum, dynamic 
signal, and modulation analyzers, as well as oscilloscopes, 
counters, and power meters. 

Importance of the 'lime Domain 

A key benefit of the microwave transition analyzer is that it 
brings time-domain analysis to RF and microwave compo- 
nent engineers. In addition to its use in pulsed RF testing, 
the time domain is essential to characterizing aild under- 
standing nonlinear devices because one can clearly and intu- 
itively see the relationship between the input ;md output 
signals. As an example, both signals in Fig. 2 w ould appear 
identical if displayed on a spectrum analyzer. Even if the 
phase of the harmonics were known, the differences be- 
tween the signals would not be immediately obvious. When 
viewed in the time domain, however, it is clear that signal 1 



is Clipped (the OUtpUl Of, a limiter. say), while signal 2 has 
crossover dist onion (what might be seen at the output of a 
C'lass-B amplifier, for example). Without the time domain, 
engineers have had to guess at the underlying causes of ob- 
served frequency-domain behavior. The ability to view micro- 
wave signals in the time domain has also proved to be ex- 
tremely valuable to designers that are using CAE microwave 
design simulators, such as HP's MDS. Now simulations 
based on circuit models can be easily compared to actual 
measurements in both the time domain and the frequency 
domain. 

Historically, most measurements on high-frequency non- 
linear devices have been performed in the frequency domain. 
Often, this has been because of inadequacies in time-domain 
instrumentation. When frequency-domain information is of 
prime concern, spectrum analyzers are superb in their abil- 
ity to display harmonic, modulation, and spurious signals 
with a huge dynamic range. However, without the phase of 
the frequency components, the time-domain signal cannot 
be reconstructed. Network analyzers are excellent for per- 
forming linear, small-signal, frequency-domain testing, but 
they are limited in their ability to characterize nonlinear 
devices. The addition of harmonic and offset sweep Capabil- 
ity in network analyzers has helped, but the time-domain 
perspective is still missing. 

For env elope analysis of pulsed-RF signals, spectrum ana- 
lyzers offer some limited time-domain capability. Recently, 
network analyzers have been adapted for pulsed-RF time- 
domain testing as well. Because of the architecture of these 
instruments, the intermediate frequency (IF) bandwidth 
imposes an upper limit on the measurement bandwidth. The 
result is minimum measurable edge limes of greater than 
100 ns. The microwave transition analyzer's architecture 
does not have this restriction. Edge speed is limited only by 
the RF bandwidth. Consequently, magnitude and phase mea- 
surements on pulses with rise times as fast as 25 ps are pos- 
sible. Fig. :l shows an example of a microwave transition 
analyzer measurement. 
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Fig. 1. Kxatnples of complex modulat ion (a) \ phase coded RF 
pulse. Tlic waveform and magnitude demodulation are shown in 
the upper half. The earner's phase with respect to a ("W reference 

is shown in the lower hair (i>) Frequency inoiluianon inside an BP 
pulse The waveform and magnitude demodulation are shown ai 
the top, the frequency demodulation is shown in the middle, and 
I he magnitude spectrum of the pulse is shown al the bottom 

The ability to measure narrow pulses in I he lime domain can 
also be used to determine the impulse response (and there- 
fore magnitude, relative phase, and group delay) of frequency 
Iranslalion components such as mixers and receivers. By 
stimulating these devices with a narrow pulse of RF energy, 
time-domain distortion can lie directly observed. Often, it is 
the time-domain distortion that is of interest, even though it 



may be specified indirectly as magnitude and phase flatness 
versus frequency. By transforming the input and output 
pulses to the frequency domain with the built-in fast Fourier 
transform (FFT) and computing their ratio, the transfer 
function is obtained. From this, familiar results of magni- 
tude and group delay versus frequency can be displayed. 
Network analyzers are only able to measure the phase and 
group delay of frequency translation components relative to 
a reference or "golden" device. 

It is much easier to measure nonlinear devices at low fre- 
quencies than at RF and microwave frequencies. At low fre- 
quencies, general-purpose oscilloscopes readily show time- 
domain behavior, and dynamic signal analyzers provide both 
magnitude and phase in the frequency domain. The only tool 
available for high-speed time-domain measurements before 
the microwave transition analyzer has been the high- 
frequency sampling oscilloscope. Initially, sampling oscillo- 
scopes were purely analog instruments, and in the past few 
years have incorporated digital storage and other enhance- 
ments such as markers. However, these instruments have 
not enjoyed widespread acceptance from RF and microwave 
engineers for several reasons. The first is the difficulties 
involved in achieving reliable external triggering at high fre- 
quencies and small signal levels. High-speed sampling oscil- 
loscopes have enjoyed the most success for use with digital 
signals where voltage levels are generally large and triggers 
are not difficult to obtain. Secondly, traditional sampling 
oscilloscopes are not very sensitive, especially compared to 
network and spectrum analyzers. The microwave transit ion 
analyzer incorporates selectable filters to decrease noise 
without limiting the signal bandwidth. The resulting increase 
in sensitivity combined with internal triggering across the 
full BP bandwidth greatly aids in the measurement of small 
signals. 

Excellent sensitivity also helps overcome a limitation of 
sampling oscilloscopes for high-input-impedance measure- 
ments ( >">() ohms). Until recently, it has been very difficult 
to obtain probes with low enough parasitic capacitance to 
be useful at microwave frequencies. Companies now offer 
solutions for high-frequency passive probing, but signal at- 
tenuation is significant. This signal attenuation is not a prob- 
lem for the microwave transition analyzer because of its 
high sensitivity. This has been especially beneficial for prob- 
ing monolithic microwave integrated circuits l.MMIt's) al the 
wafer level. 

Finally, the operation of high-speed oscilloscopes lias not 
been optimized for RF and microwave applications, where 
terminology is often different from that used in digital design, 
The user interface of I he microwave transition analyzer uses 
units and formats that are familiar to RFand microwave 
engineers. For example, log-magnitude displays of pulsed- 
RF signals are readily available, and marker annotation can 
be in dBin or dBc as well as volts. 

Microwave Transition Analyzer 

The IIP 71500A microwave transition analyzer (Fig. 4) is a 
two-channel, sampler based instrument with an RF band 
width covering from dc to 40 (illz. The instrument is called 
a transition analyzer because of its ability to measure very 
fast magnitude and phase transitions under pulsed-RF con- 
ditions. However, this name does not encompass the full 
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Fig. 2. The importance of phase information in nonlinear design. -Signals 1 unci - would appear identical on a speelrum analyzer display 



range of its measurement capability. The microwave transi- 
licm analyzer can hesl he described as a cross between a 
high-frequency sampling oscilloscope, a dynamic signal 
analyzer, and a network analyzer. 

Like a digilal sampling oscilloscope, the microwave transi- 
tion analyzer acquires a waveform by repeliiively sampling 
the Input, thai is, one or more cycles of the periodic input 
signal occur between consecutive sample points. However, 
unlike an oscilloscope, the sampling instant is not determined 
by an external high-frequency trigger circuit. Instead, the 
sampling frequency is synthesized, based on the frequency 
of the input signal and the desired time scale. A synthesized 
sampling rale is an attribute that lite microwave transition 
analyzer shares with dynamic signal analyzers. Also in com- 
mon is an abundance of digilal signal processing capability 
The FFT, for example, allows simultaneous \iewing of the 
time waveform and its frequency spectrum. However, unlike 
a dynamic signal analyzer, the microwave transition analyzer 
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Fig. 3. The microwave transition analyzer c an measure edge 
speeds on modulated waveforms as fast as 23 ps. 



does not have an anti-aliasing filter at its input. The sampling 
frequency is automatic-ally adjusted to achieve a controlled 
aliasing of the frequency components of the input signal. 
Finally, like a network analyzer, the microwave transition 
analyzer can be configured to control a synthesized signal 
source for the characterization of devices over frequency or 
power ranges. It can also receive a frequency that is offset 
from or a harmonic of the source frequency, and it can pro- 
vide frequency and power sweeps al a particular point within 
a pulse of RK. on pulses ns narrow as 1 ns. 

Architecture 

Fig. 5 shows a simplified block diagram of the microwave 
transition analyzer. The analyzer has two identical signal 
processing c hannels. Each channel samples and digitizes 
signals over an input bandwidth of dc to 40 GHz. The chan- 
nels are sampled simultaneously ( within 10 ps). permitting 
accurate ratioed amplitude and phase measurements. A 
single synthesized low-noise oscillator drives a step recov- 
ery diode, the output of Which is split into two pulse trains 
that drive the microwave samplers. The microwave sam- 
plers and the analog-lo-digital converters (ADCs) are run at 
the same frequency. The maximum sampling frequency is 
20 MSa/s (20 million samples per second ). 

The signal al the output of the samplers is processed by a 
10-Mllz-bandwidlh low-pass IF strip. The \¥ (intermediate 
frequency) circuit ry includes a programmable shaping am- 
plifier to compensate for the sampler's IF response roll-orf, 
60 dB of step gain to optimize the signal level into I he ADC, 
and variable low-pass filtering to remove noise and sampler 
feedthrough. The trigger circuitry is al the end of the analog 
path. Triggering on IF signals (instead of RF input signals) 
allows the microwave transition analyzer to be internally 
triggered to 40 tillz. Enhancements to the hardware irigger 
are available through the use of digital signal processing. 

Periodic Sampling 

The mathematical analysis of periodic functions was begun 
in the early 19th century by Jean-Baptiste-Joseph Fourier. 
Fourier's theorem introduc ed the techniques for decomposing 
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Fig. 4. Named for Its ability to measure very fast magnitude and 
phase transit inns Under pulsed-RF conditions, tiie HI' 71 Til IDA 
microwave transition analyzer (top instrument) is part high- 
frequency sampling oscilloscope, part dynamic signal analyzer, 
and part network analyzer. The HP 71i>00A consists of the HP 
78020A microwave transition analyzer module and the HP 70004A 
mainframe The lmttom instniment shown here is the HP 83640A 
synthesized sweeper. 

any periodic waveform into a sunt of harmonically related 
sinusoids. The Fourier scries is ;i frequency -domain repre- 
sentation of the original time function and is used to sim- 
plify the description and provide insight into the function's 
underlying characteristics. 

The sampler in I he microwave transition analyzer is driven 
hy a constant-frequency sampling signal. Because the sain 
pier drive is periodic, Fourier analysis can be used to under- 
stand the sampler's operation. Often, periodic- signals or 
systems responding to periodic signals are described and 
analyzed in the frequency domain. Transformations be- 
tween I he litne and frequency domains replace convolution 
operations in one domain with multiplication in the other. 



Filtering, a convolution operation in the time domain, is 
more easily interpreted as frequency-domain multiplication. 
Alternatively, a mixer multiplies two signals in the time do- 
main, but the result is expressed as frequency -domain 
translation, a convolution operation. Why convolution is the 
anaiytica] mechanism for realizing frequency translation is 
explained in "Frequency Translation as Convolution" on 
page 61. 

An ideal sampler driven by a periodic sampling pulse can be 
considered a switc h that briefly connects the input port to 
the output port at a periodic rate. When the switch is closed, 
the output signal is the input signal multiplied by unity. 
When the switch is open, the output signal is grounded, that 
is, the input signal is multiplied by zero. Thus, the signal at 
the sampler's output is formed as the product of the input 
signal and the periodic pulse defining the switch state as a 
function of time. .As in the mixer example on page 61, time- 
domain multiplication results in frequency-domain convolu- 
tion. The frequency spectrum of the sampler's input signal is 
convolved with the spectrum of the periodic pulse to produce 
the spectrum of the sampler's output (IF) signal. 

The frequency spectrum of a periodic pulse is composed of 
delta functions at the fundamental repetition frequency and 
all multiples (harmonics) of this frequency. This Infinite set 
of impulses in the frequency domain, sometimes called a fre- 
quency comb, inherits a magnitude and phase profile accord- 
ing to the time-domain pulse shape. A narrow, rectangular 
pulse imparts a sin(f)/f roll-off characteristic to the frequency 
comb. The first null of the response occurs at a frequency 
equal to the reciprocal of the pulse width and the 3-tlH atten- 
uation frequency occurs at 0.443 times this value. Funda- 
mental to wide-bandwidth sampling is achieving a very nar- 
row sampling pulse or aperture. The sampling aperture in 
the microwave transition analyzer is less than 20 ps. 

The sampling front end of the microwave transition analyzer 
converts the high-frequency Input signal to a low-ftequeney 
IF signal suitable for digitization and subsequent numerical 
processing. Depending on the applic ation, three different in- 
terpretations of the sampling process are possible: Frequency 
translation, frequency compression, and a combination of 
translation and compression. 




Samplers Low-Pass Slop Gain Circuits ^7 

Fillers Amplifiers 

Fig. 5. Simplified block diagram of the HP 7150GA microwave transition analyzer. 
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Frequency Translation 

Nonrcpetilive or single-shol events can be raptured by sam- 
pling the input signal at a rale greater Hum twice the input 
bandwidth. This is known as the Nyquist criterion. However, 
maintaining this criterion does not imply that the sampling 
rate must he greater than twice the input signal's highest 
frequency; If ihe RF bandwidth of the sampler is adequate, 
narrowband information on a high-frequency carrier can he 
captured by low-frequency sampling, as long as a sampling 
rate of approximately twice the modulation bandwidth is 
maintained. Sampling the high-frequency signal translates 
the signal lo baseband. 

Samplers are often used in place of mixers for frequency 
conversion — for example, in the front ends of many general- 
purpose network analyzers. In the case of translation only, a 
given narrow frequency band is convened to baseband by 
an appropriate choice of sampling frequency. Fig. li diagrams 
I he conversion process. The sped nun of I he input signal is 
shown in Fig. lia and the frequency comb of the sampling 
pulse is shown in Fig. 6b. The sampling frequency, [hat is. 
the spacing bel ween the teeth of the frequency comb, is 
chosen such that the input spectrum lies appropriately posi- 
tioned between adjacent comb teeth. The convolution result 
is shown in Fig. 6c. 

Two important considerations in the choice of sampling fre- 
quency can be seen from these diagrams. First, the input 
signal bandwidth (Fig. lia) must be less than one half the 
sample rate. Second, the sample rale must be chosen so the 
input spectrum is entirely contained in a frequency range 
bounded by the nearest sampling harmonic and the frequency 
halfway to the next higher or lower harmonic. If these crite- 
ria are not met, the sampler will translate or alias more lhan 
one component of the input spectrum lo the same output 
frequency, causing uncorrectable errors. The maximum sam- 
pling rale of the microwave transition analyzer is 20 MSa/s. 
The rate is continuously adjustable ( in 1-niHz steps) clown 



to a minimum rale of 1 Sa/s and can be phase-locked lo an 
external 10-MHz reference. 

The signal at the output of Ihe sampler is amplified and low- 
pass filtered before analog-to-digital conversion. This filter- 
ing virtually restores the original input spectrum, but ii is now 
centered in the much lower IF range (Fig. (id). Because Ihe 
filter transition front passhand to stopband is not immedi- 
ate, some undesired high-frequency energy may be included 
in the signal presented to the ADC. In this case, the band- 
width of the signal at the ADC exceeds half ihe sample rate. 
Aliasing occurs as the highest -frequency components are 
folded back on top of the original translated spectrum by 
Ihe sample-and-hold circuit of the ADC. However, unlike 
the aliasing problems mentioned in Ihe prev ious paragraph, 
the effects of litis aliasing can be predicted and corrected 
in software because the aliased components represent 

redundant Information. 

In summary, using a sampler With a bandwidth many limes 
the sample rate allows the capture of single-shot events in 
the modulation on a high-frequency carrier (see Fig. 7). The 
analysis bandwidth is limited lo half Ihe sample rate. 

Frequency Compression 

A second, fundamentally different perspective of Ihe sam- 
pling process is useful in Ihe measurement of periodic high- 
frequency signals. Traditionally, these measurements have 
required trigger-based repetitive sampling techniques. In ihe 
microwave transition analyzer, precision RF I rigger circuit ry 
is not used. Periodic sampling alone is used lo convert a 
strictly periodic input with harmonic components spread 
across a very wide bandwidlh to a low-frequency signal with 
harmonic components spread over the narrow IF range. This 
is accomplished by choosing a sampling frequency that con- 
veils each component of the input signal into the IF such that 
the harmonic ordering, magnitude, and phase relationships 
of Ihe original input are preserved in Ihe IF signal. The sam- 
pling process effectively compresses the wide-bandwidih 
input signal Into a low-frequency signal at the IF. 
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Fig. 7. Ttun-on Characteristic of a synthesizer's output amplifier. 
This single-shol measurement was internally triggered on the 

signal thai originated from the enabling of the RF output of the 

synthesizer. The earner frequency is 5 GHz. 
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Fig. 8. Sampling used to frequency compress a periodic input 
signal, (a) Input signal spectrum, (h) Sampling comb, (c) Expand- 
ed frequency scale showing the relationship bel ween the input and 
the sampling signal components, (d) The sampler output signal is 
the convolution of the waveforms in (a) and |'b). 

Fig. s illustrates the concept in the frequency domain. The 
input spectrum and frequency comb of the sampling pulse 
(including I he RF response roll-off) are shown in Figs. 8a 
and 8b, Fig. 8c provides a close-up view of the relative posi- 
tioning of the comb lines wilh respect to the input signal. 
The sampling rate is chosen such that a given harmonic (I he 
nib) is positioned x Hz below the input's fundamental fre- 
quency. Then, I he ( lin Hh sampling harmonic will be posi- 
lioned 2x below the input's second harmonic, the (-'In )th 
sampling harmonic will be -"fx below the input's third har- 
monic, and so on. Fig. 8d shows the result of the convolu- 
tion. Each harmonic of the input is converted to a corre- 
sponding harmonic of the low -frequency signal at the IF. 

The sampler does not have infinite bandwidth, and the 
sin( f)/f roll-off of the sampling comb attenuates the IF re- 
sponses that correspond to input components at the higher 
frequencies. Small amounts of attenuation may be compen- 
sated for in software, however, after the signal is digili/.ed. 
The combination of a very narrow sampling aperture and 
software corrections allow the microwave transition analyzer 
lo specify a flal response to 10 GHz. 

Viewing this process in the lime domain, the sample interval 
is set to be a multiple of the inpul period plus a small amount 
equal to the effective lime between points (Fig. !■)). Since the 
sampling Interval is not an exact multiple of the input period, 
the sampling instant moves wilh respect to the input al a 
prescribed increment as the samples are acquired. The effec- 
tive time between points is determined by how close I he sam- 
pling frequency is lo a subharmonic of the input frequency. 



Compression Factor. The signal at the IF is a replica of the 
input signal, but at a much lower fundamental frequency. 
When this signal is digitized and displayed, the waveshape 
matches that of the input. The time range indicated on the 
display is calculated by dividing the real lime (sample period 
times trace points I by the compression factor (input frequency 
x 1/x. where x corresponds to the fundamental frequency at 
the IF— see Fig. 8): 



Time Span = 



(Sample Period) i Number of Trace Points) 
(Input Frequency)/x 



When the microwave transition analyzer is used for repeti- 
tive sampling, the inpul signal must be strictly periodic, and 
the period must be known to high accuracy. If the frequency 
that the analyzer assumes for the inpul signal is near but not 
exactly equal to the frequency of the signal being measured, 
the IF will be shifted in frequency by an amount equal to the 
difference. The resulting measurement will show an erro- 
neous time scale, the error equal in percentage to the fre- 
quency error of the IF signal. Thus, a small RF inaccuracy 
can result in a very large time-scale error. The ability lo fre- 
quency-lock the microwave transition analyzers sampling 
rate to the signal being measured (by sharing a common 
reference frequency with I he stimulus), removes this source 
of error. The resulting l ime scale accuracy is specified to 1 
ps — better than any current trigger-haseri oscilloscope. 

Triggering. To keep the display "triggered," low-frequency 
trigger circuitry' is connected to I he IF signal and used to 
iniliate the storage of a dala record relative to a rising or 
falling edge. Dala samples in the buffer before the trigger 
occurrence are displayed as negative time (prel rigger view). 
Through the combination of periodic sampling and a low- 
frequency trigger circuit, the microwave transition analyzer 
is able lo I rigger internally on periodic signals across the lull 
Ki t 111/ input bandwidth and offer negative-lime capability 
without delay lines. 

IF Filtering for Noise Reduction. As mentioned earlier, the sig- 
nal at the oulpul of the sampler is low-pass filtered before 
analog-to-digital conversion. In Fig. Sd I he bandwidth cho- 
sen for this filtering is less than half I he sampling rale. Any 
IF components above the band edge Of the filler correspond 
to inpul harmonic components beyond the specified input 
bandwidth Of 40 GHz and may be tillered off. Filtering the IF 
signal to a bandwidlh narrower than half the sampling rale 
means dial not all of the noise across the 40-GIIz inpul band- 
widlh is converted to noise on the IF signal. Thus, noise is 
removed from the displayed signal without affecting the 




Fig. 9. Periodic sampling in the time domain 
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Fig. 10. Filtering the IF signal removes noise hm retains the 
underlying wave shape 

waveshape. The result is cleaner displays and improved 
sensitivity (hy more than 20 (115) compared to conventional 
trigger-based sampling oscilloscopes (see Fig. 10). 

Translation and Compression 

The perspectives of translation and compression are com- 
bined lo analyze the third use of the microwave transition 
analyzer's sampling front end. The application is measuring 
signals composed of broadband, periodic modulation on a 
high-frequency carrier. Examples include pulsed-RF signals 
with narrow pulse widths or fast edge speeds. Proceeding as 
before, the spectrum of the input signal and the frequency 
comb of the sampling pulse are shown in Figs. 1 la and 1 lb. 
respectively. Fig. 11c has an expanded frequency scale show- 
ing the relative positioning of the input's spectral lines and 
those of the sampling pulse. Two variables, x and y. are intro- 
duced in this figure, and are related to the concepts of com- 
pression and translation, respectively. The sampling frequen- 
cy is chosen such that the signal's pulse repetition frequency 
( PHF) is slightly greater (x Hz) than a multiple of the sam- 
pling rate. In other words, the time between sampling 
instants is slightly greater than an integral number of input 
pulse repetition periods. As can be seen from the diagram, 
the frequency separation between a given signal component 
and the nearest sampling harmonic increments hy x Ilz 
when considering the next-higher signal component. Conse- 
quently, the spacing of the corresponding components in the 
sampler's output signal is x Hz, resulting in a compression 
factor of PRF/x. 

In Fig. 1 lc. the spectral center of the input signal is shown 
to be offset by y Ilz from the nearest sampling harmonic. 
Therefore, the signal at the output of the sampler is centered 
at y Hz. as shown in Fig. 1 Id. If the offset y is allowed lo 
decrease by a change in the input carrier frequency, the sam- 
pler output components are translated toward one another 
as indicated by the dashed arrows. If y becomes too small, 
the components will partially overlap and distort the spec- 
trum. Likewise, if y is increased, the sampler's output com- 
ponents move opposite lo the directions indicated and will 
overlap as y approaches half the sampling rate. 



For a given pulsed-RF input signal with an arbitrary carrier 
frequency, the values of x and y cannot be independently 
controlled by adjustments in the sampling rate alone. If the 
sampling rate is set to achieve the desired compression fac- 
tor (PRF/x). there is no remaining degree of freedom for 
adjusting the spectral offset (y) to avoid overlap. One solu- 
tion is to provide a mechanism for automatically adjusting 
the carrier frequency under control of the microwave transi- 
tion analyzer. In many cases, the microwave transition ana- 
lyzer is used in a stimulus-response configuration similar lo 
I hat of a net work analyzer. If I he carrier source is under 
control, the carrier frequency control can be used to adjust 
the spectral offset independent of the sampling rate. 

Often, however, the microwave transition analyzer does not 
control the carrier source, or it is desired that the carrier 
frequency not be modified. In these cases, the simultaneous 
requirements on the sample rate are achieved by slight mod- 
ifications to either the requested time span or the number of 
trace points. The parameter to be modified is determined by 
the user. Remembering that the displayed time span is equal 
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Fig. 11. Sampling used to analyze periodic wideband modulation, 
(a) Input signal spectrum, (b) Sampling comb, (r) Expanded fre- 
quency scale showing the relationship between input and sampling 
signal components, (d) The sampler output signal is the convolution 
of the waveforms in (a) and (b). (e) The IF spectrum on an expand- 
ed frequency scale, showing t he spacing of the signal components 
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Fig. 12. Mosi digital signal processing algorithms require sampling the input signal at a uniform interval (a) In the microwave transition 
analyzer, the sampler is driven at a synthesized rate, resulting in very precise sample liming. fl>) Conventional sampling oscilloscopes rely 
on high-frequency trigger circuitry for timing accuracy, so the sampling interval can be considerably more uncertain. 



to the real lime divided hy the compression factor, the 
following equation results: 



Time Span = 



(Sample Period) (Number of Trace Points) 
PRF/x ' 



Since the input PRF is a constant and x is a function of the 
PRF and the sampling rate (see Fig. I lc), the above equation 
relates the three variables: time span, number of t race points, 
and sampling period. Fixing either the lime span or the num- 
ber of trace points and slightly adjusting the other quantity 
results in a small change in the sampling period. A small 
change in sampling rate causes a much larger shift in the har- 
monic nearest the input carrier, in this fashion, the centering 
of the spectrum at the sampler's output is controlled. 

Numerical Processing 

Discussion to this point has concentrated on how the sam- 
pling process can be used lo translate and/or compress a 
high -frequency input signal into a low-frequency signal at 
the IF suitable for digitization. [Squally important for the 
microwave transition analyzer is the processing done on 
the signal after it has been digitized. Conventional digital 
signal processing algorithms, such as digital filtering, 



demodulation, and FFT analysis, assume that the input 
signal has been sampled at an exact, uniform rale. In the 
microwave transition analyzer, the sampling interval is syn- 
thesizer-based, resulting in sample-lo-sample liming that is 
precisely uniform. A single trigger event initiates the storage 
of an entire trace of data. By contrast, conventional sam- 
pling oscilloscopes rely on high-frequency trigger circuitry 
lo provide a consistent sampling interval. Since ;i different 
trigger event is used for the measurement of each data point, 
any triggering uncertainty results in saniplc-to-sumple timing 
variations. Because the triggering accuracy is dependent 
both on the (trigger) signal characteristics and the amount 
of trigger delay selected, the resulting sampling interval can 
become significantly nonuniform under certain conditions, 
reducing the options for fun her numerical processing (sec 
Fig. 12). 

Analytic Signal Representation. I tae of the First operations 
applied lo the sampled data is the creation Of the quadrature 
function using the Ililbert transform. This quadrature func- 
tion is combined with the original data lo form a complex- 
valued representation of the waveform called the analytic 

sitjiial. Just as complex-valued phasor representations 
simplify the analysis of linear circuits, the analytic signal 
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simplifies the manipulation and analysis of modulated wave- 
forms. Use of the analytic signal representation also allows 
for vector normalization of traces, an operation normally 
found in network analyzer systems. 

RF and User Corrections. One of the more obvious uses for 
additional processing of the sampled data is to compensate 
for nonideal conditions in the analog circuitry. As men- 
tioned, the sampler has a frequency response characteristic 
largely determined by the aperture time of the sampling 
pulse. The magnitude response of the sampler is measured 
at the factory and stored inside the analyzer. This data is 
then used to correct for I he sampler roll-off in subsequent 
measurements. Regardless of whether the sampler is used 
for translation or compression, an assumed, unique mapping 
exists between IF frequency and input RF frequency. When 
the IF signal is digitized, an FFT is used to convert the re- 
sponse into the frequency domain. The IF frequencies are 
mapped into RF frequencies, (he appropriate correction at 
each frequency is applied, and the result is then transformed 
hack to the time domain for display. The same processing 
routines are also available for user-definable filtering or 
corrections. User-defined corrections are useful in compen- 
sating for cabling or fixturing losses. Filtering applications 
might include simulating the magnitude and phase charac- 
teristics of a transmission channel to predict what effects 
the channel will have on specific signals. 

Frequency-Domain Measurements Using the FFT. The ability to 
execute transformations quickly between the time and fre- 
quency domains is important to the operation of the micro- 
wave transition analyzer. These tasks arc accomplished by a 
pair of digital signal processing chips ( one per channel) 
tightly coupled to the ADC memory. If the user requests a 
frequency-domain display, the signal is shown after frequen- 
cy corrections are applied without the transformation back 
to the time domain. Separate frequency-domain controls 
allow the user to zoom in on a narrow portion of the original 
frequency span. This is accomplished by processing a longer 
time record with the FFT and displaying only part of the 
frequency outputs. 

As mentioned above, the microwave transition analyzer as- 
sumes a unique mapping between the IF and RF frequencies, 
resulting in a replicated version of the input signal at the IF. 
How-ever, if a second, unrelated signal is present at the input, 
it too is converted to the IF and becomes part of the sampled 
signal. The components of this second signal will fall at seem- 
ingly arbitrary IF positions and will not correspond at all to 
the IF-to-RF mapping that the first signal obeys. Except for 
the operating mode described below, the microwave transi- 
tion analyzer is designed, like most oscilloscopes, for the 
measurement and display of a single signal. 

If multiple, nonhannonically related signals are known to be 
present at the input, the microwave transition analyzer can 
be instructed to measure these signals independently using 
the table mode of operation. In the table mode, the funda- 
mental and harmonics of up to five signals arc measiu'ed, 
using the FFT to measure each component of each signal 
individually. The sampling frequency is chosen to avoid con- 
verting different spectral components to the same frequency 
at the IF. The results are displayed in tabular form ( see Fig. 
13). The table baa be updated continuously for only one of 
the signals or for all of them. If a waveform display is desired. 
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Fij{. 13. Microwave transition analyzer table mode displays, (a) 
Tin - output of a mixer shown in the time-domain display at the top 
is the combination of several signals. The table displayed at the 
bottom provides information about the frequencies present, (b) 
The table is configured to display information for only one or The 
signals present . The second trace at the top is constructed from 
this measurement rial a. 

a data trace can be constructed according to the table values 
and the specified lime span. This capability allows the micro- 
wave transition analyzer to display time-domain signals in a 
frequency-selectiv e fasltion, combining some of the attributes 
of both oscilloscopes and spectrum analyzers. 

Phase Trigger. Another use of the microwave transition ana- 
lyzers FFT resources is in measuring low-level or noisy sig- 
nals. Trace averaging is used by oscilloscopes to reduce 
noise on a displayed waveform, However, averaging can 
work only if the waveform is reliably triggered, which is 
difficult on low-level or noisy signals. In the microwave tran- 
sition analyzer, waveform capture is not dependent on reli- 
able triggering, but on knowing the input frequency and sam- 
pling at the proper synthesized rate. If at least one period of 
the signal is collected into memory on every' sweep, the trig- 
ger point will always be somewhere in this record of data. 
The microwave transition analyzer introduces a special 
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Fig. 14. Very small ornois>' signals can be reliably triggered with 
Uie microwave transition analyzer's phase trigger. Sweep-to-sweep 
averaging can then be useil tu reduce the noise. 

trigger mode, called phase I rigger. The trigger value is speci- 
fied in terms or the phase of the fundamental component of 
the signal. An FFT is used to measure the phase of the fun- 
damental at the midpoint of the time record. From this, the 
index in the record that corresponds to the (rigger point is 
determined, and the correct portion of the record is copied 
to the display trace. Although the trigger point in the larger 
memory record may move about from sweep to sweep, the 
display trace stays triggered. The result is that processing 
gain (via the FFT) has been applied to extract the trigger 
information, allowing stable triggering on even very noisy 
signals ( Fig. 14). Trace averaging can then be used to reduce 
I he noise on the displayed waveform. 

Component Test Systems 

Electronic components are most often tested by measuring 
their response to a given stimulus. The stimulus source can 
be anything from an impulse generator to a sweep oscillator 
or a synthesizer. The measurement instruments include os- 
cilloscopes, spectrum analyzers, and dedicated receivers. 
Stimulus and measurement functionality are frequently com- 
bined to form a stimulus-response system. Network analyz- 
ers, spectrum analyzers with tracking sources, and oscillo- 
scopes with built-in step generators are examples of systems 
in which ihe stimulus source is controlled directly by the 
measurement instrument. The microwave transition ana- 
lyzer, with its buill-in pulse generator and ability to control 
synthesizers over a private HP-IB (IEEE 488, IEC (525). can 
be configured as a versatile stimulus-response system for 
component or system test 

An advantage of configuring the microwave Iransilion ana- 
lyzer as a stimulus-response system for time-domain niea- 
suremenis is that the analyzer is always certain of the signal 
frequency. Configuring Ihe Stimulus under the control of the 
microwave iransilion analyzer and sharing a common 10-MHz 
reference ensures agreement between the assumed and ac- 
tual input frequencies, Additionally, indirect adjustmenl of 
Ihe stimulus via the controls of the microwave transition 
analyzer allows interesting new time-domain capabilities. 
< hie is ihe ability lo hold a fixed number of signal periods on 



Ihe display regardless of the stimulus frequency. In other 
words, the time range is automatically updated at any change 
of stimulus frequency. Using this feature, designers can see 
changes in a devices response as it operates over a range of 
frequencies, without the continuous time scale adjustments 
that w ould be required w ith a convent ional oscilloscope. 

RF and microwave design engineers are familiar with the use 
of synthesized signal generators for testing their devices. 
However, for designers requiring a nonsinusoidaJ stimulus, 
synthesized pulse generators are not generally available. 
The repetition interval of most pulse generators is not con- 
stant enough for repetitive sampling with the microwave 
transition analyzer. To ease this problem, the analyzer pro- 
vides a variable-rate, TTL-level output pulse that is frequency- 
locked to the sample rate synthesizer. The pulse width and 
period are adjustable in 100-ns increments. This output can 
be used directly or as the trigger input lo a standard pulse 
generator, thereby locking the repetition rate to the time base 
of the microwave transition analyzer. If the pulse is used for 
modulating a carrier, the analyzer needs lo know the carrier 
frequency to sample the signal at the correct rate. (See the 
earlier discussion on translation and compression. ) For 
stimulus-response testing under pulsed-RF conditions, 
this is most easily accomplished by having a configured 
synthesizer supply the carrier. 

The automatic control of a sinusoidal signal generator by 
the microwave transition analyzer results in an instrument 
system with the flexibility to measure the response of a de- 
vice as a function of time, input frequency, or input power. 
In addition lo showing time-domain responses like an oscil- 
loscope at various inpul frequency and power levels, the 
analyzer can automatically slep the source across a frequency 
or power range and provide measurement functionality simi- 
lar lo that found in network analyzers, Al each point in a 
frequency or power sweep, the magnitudes a,1( ' phases of 
the sinusoids at the two inpul channels are measured by col- 
lecting a set of lime samples and applying the PPT. Increasing 
the number of time samples used in the FFT is equivalent to 
decreasing the processing bandwidth and results in a more 
accurate measurement (at the expense of sweep speed ). 
Because of the frequency discrimination provided by the FFT. 
the measured frequency need not be the same as the stimu- 
lus. Conversion l ()SS >" devices responding al frequencies 
llial are offset from or harmonic multiples of the stimulus is 
easily measured wilh Ihe microwave iransilion analyzer. 

Signal Test Applications 

For signal test as opposed to component test applications, 
the microwave Iransilion analyzer is used as a stand-alone 
instrument. Repetitive sampling siill requires Ihe signal lo be 
periodic, but radar and communication systems are increas- 
ingly moving m highly stable, synthesizer-based designs 
locked to a common reference. Hewlett-Packard's frequency 
agile signal simulator I FASS ) is an example. Many times, the 
testing of these systems can be accomplished wilh the system 
in a periodic operating mode. 

In applications w here Ihe signal frequency is unknown, Ihe 
microwave transition analyzer can be used like a counter lo 
determine the signal frequency to high precision. This is 
accomplished by taking several measurements of ihe input 
signal al differeiil sampling rales and comparing I he change 
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Fig. 15. I'roct'sstag fovv In the Stationary sampling mode of operation. 

in the IK to the change in sampling rate: 1 PorGW signals 

with at least a 10% duty cycle, I he microwave transition ana- 
lyzer will determine the frequency to an accuracy of 1 pan 
in 10 s . If multiple signals are present at the input, the funda- 
mental frequency for each (up to a maximum of live) will be 
returned. The analyzer is also able to measure the carrier 
frequency Of pulse modulated signals for pulse widths as 
narrow as :«)() ns. Because the data acquisition for this mea- 
surement is single-shot, the pulse repetition interval need 
not be constant 

Stationary Sampling Mode 

A measurement mode known as stationary sampling offers 
significiuit enhancements to the microwave transition analyz- 
er's pulsed-RF capabilities. Stationary sampling is a technique 
that substantially reduces the trace noise on lime-domain 
displays, resulting in increased sensitivity and dynamic 
range. Furthermore, it is through stationary sampling that 
pulsed network sweeps of frequency and power are 
achieved. Fig. 15 illustrates the process. 

A prerequisite for stationary sampling is that the carrier fre- 
quency is not a harmonic multiple of the modulation period. 
That is. the modulation is not coherent with the carrier. Un- 
der this assumption, if the microwave transition analyzer 
samples the signal at a rate equal to the modulation rate, the 
sampling instant stays fixed with respect to the modulating 



envelope, but not with respect in Hie carrier. This is illus- 
trated at the bottom of the figure. The sampling rale is set to 
be either equal to or an exact submultiple of the pulse repe- 
tition frequency. The resulting set of samples describes the 
carrier waveform at a particular point in the pulse. The data 
is then passed through a narrowband filter implemented 
with an FFT. This filtering acts to suppress noise and sepa- 
rate the carrier fundamental from dc and harmonic compo- 
nents. The complex-valued FFf output bin corresponding to 
the frequency of the sampled carrier represents one (ana- 
lytic) time sample of the filtered waveform. This output 
becomes one data point in the final trace. 

The next trace point needs to be taken at a different position 
with respect to the modulating envelope. To accomplish 
this, the interna] synthesizer controlling the Sampling rale is 
phase-shifted a precise amount. This moves the sampling 
instant the desired time increment along the modulating 
envelope. A new set of earner samples is collected, pro- 
cessed with the FFT. and another complex valued output 
point is stored to the final trace. The process is repeated for 
every trace point. The amount of filtering that is applied in 
creating the output trace is adjustable by the user and is 
directly related to the number of time samples used in the 
FFT. 
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The sampling and filtering process separates the RF com- 
ponent from the dc component at each |»oint in the pulse. 
Depending on which FFT output bin is recorded, either the 
dc feedthrough or Uie RF portion of the input waveform is 
ultimately displayed (see Fig. 15). This eliminates the re- 
quirement for the user to supply external filtering when 
performing these measurements. Also, measurements of 
carrier distortion at a particular point in the pulse are pos- 
sible by setting the time span to zero. The FFT filtering in 
Fig. 15 is omitted and the sampled carrier is directly dis- 
played. The measurement point is controlled by adjusting 
the trigger delay. Transforming the carrier waveform into 
the frequency domain allows easy measurement of the 
distortion components. 

For pulsed network analyzer sweeps, when the sweep axis 
is frequency or power, the operation is very similar to that 
described for time sweeps. A triggering process aligns the 
measurement poini with respect to the modulating enve- 
lope. Then, instead of phase shifting the sample rate synthe- 
sizer between each trace point, the carrier's frequency or 
power is automatically stepped. The result is a measure of 
the response of the device as a function of carrier frequency 
or power at a particular point in the modulating envelope. In 
conventional pulsed network analyzers, the IF bandwidth 
sets limitations on edge speed and pulse width. In the micro- 
wave iransition analyzer, the measurement is performed 
using repetitive sampling techniques, and ihe modulation 
bandwidth is limited only by the sampler's RF response. 

User Interface Design 

The user-interface design of an instrument as versatile as 
the microwave transition analyzer required considerable 
work. lis feature set includes functionality found in a variety 
of microwave lesi equipment The Interface must not only 
provide control for displays of voltage versus time like an 
oscilloscope, magnitude versus lime like a peak power meter, 
and phase or frequency versus lime like a modulation do- 
main analyzer, bill must also allow for the automatic control 
of an external synthesizer, providing C'W and pulsed network 
measurements of magnitude and phase versus frequency or 
power. Additionally, the FFT can be used for harmonic anal- 
ysis, showing a display similar to I hat of a spectrum analyzer, 
and the automatic signal acquisition routines can be used to 
provide runctioiialily found in CW and pulse counters and 
vector voltmeters. 

The challenge in any interface design is lo balance the rc- 
quiremenl of complete functional access wilh Ihe need for 
simple, intuitive controls for specific, targeted applications. 
One approach suggested early in Ihe development cycle was 
lo have the microwave transition analyzer assume differenl 
instrument personalities. For example, Ihe user would 
(in lose an oscilloscope interface for one measurement, then 
switch to a network analyzer interface for a second inea- 

surement, then io a spectrum analyzer for another, and so 

on The appeal i if I his approach is obvious: users need not 
learn a new interface, liul as Ihe implementation developed. 
Ihe problems began to outweigh the benefits. 

For example, an interface constructed according to this logic 

would forbid the simultaneous display of a voliagc-vcrsus- 
liine waveform and its frequency spectrum, thereby losing a 
v aluable perspec tive in Ihe analysis of nonlinear operation. 
One of ihe major contributions of the microwave transition 



analyzer is its multidomain capabilities, and the interface 
needed to emphasize this strength. Less important, but still 
significant, is the fact that marker operation is substantially 
different for oscilloscopes, spectrum analyzers, and network 
analyzers. Any implementation that might impose three dif- 
ferent marker systems on the user would be hard to describe 
as user-friendly, yet a common marker system weakens the 
implementation of instrument-specific personalities, Most 
important, measurement features unique to the microwave 
transition analyzer have no home in such an interface. Real- 
izing this, the designers set out to c reate a versatile core 
interface targeted at two application areas: pulsed-RF or 
switched-RF component test, and time-domain analysis of 
microwave devices. Later, simplified interfaces for specific 
applications could be developed by drawing features from 
this core. 

Pulsed-RF Testing. The versatility inherent in the architecture 
of the microwave transition analyzer allows a good match to 
the needs of high-speed pulsed-RF characterization. Design- 
ers in this area have traditionally required a wide variety of 
test instrumentation. Measurements of magnitude settling 
time are possible by combining an oscilloscope, a broad- 
band detector, and a filter to remove the video feedihrough. 
Measuring phase settling time has been much more difficult, 
usually requiring Ihe use Of modulation-domain analyzers, 
pulse network analyzers, or custom down-converters, digi- 
tizers, and software. The fundamental attributes of the 
microwave Iransition analyzer's architecture — a very wide- 
bandvvidlh. dual-channel front end. a precisely uniform sam- 
pling interval, and powerful digital signal processing — pro- 
vide the elements for unprecedented measurement flexibility 
in pulsed-RF component lest. This, combined with the ana- 
lyzer's singular ability to measure magnitude and phase set- 
tling limes on edges as fasl as 25 ps. is the reason for tailoring 
Che Interface to pulsed-RF testing. 

Making it easy to demodulate a vollage-versus-limc display 
of an RF pulse and show inagnilude, log magnitude, or 
phase versus time was a key goal of Ihe implementation. 
These sophisticated digital demodulation procedures are 
accessible simply by choosing a display formal for the trace. 
The phase slope can be removed mathematically at the 
press of a billion, or Ihe phase can be measured wilh re- 
siled lo the other channel by defining the trace inpul as a 
ratio of Ihe channels. On pulse waveforms wilh excessive 
amounts of \ Idea feedthrough, the stationary sampling 
mode can be used to separate the RFand video portions of 
Ihe waveform wilh digiial tillering and display each port inn 
independently, Invoking the mode is accomplished by sim- 
plj turning on a filter. A variety of additional processing is 
available by defining a trace in terms of digital signal pro- 
cessing operations on liiamiels, memories, and other traces 
(see Fig. l(i). The resull is a powerful digiial signal process- 
ing system that is available to the user in a form that is easy 
lo understand and simple lo use. 

Recognizing the limited availability of synthesized pulse 
generators, the design team decided to include one in the 
analyzer, t sing lliis output lo control the modulation period 
and a configured synthesizer lo supply the carrier means 
thai all stimulus adjustments are controlled through the inter- 
lace of Ihe microwave transition analyzer. Since the analyz- 
er needs lo know these signal parameters lo sel the correct 
sampling rale, a configured setup eliminates the (sometimes 



© Copr. 1949-1998 Hewlett-Packard Co. 



October 1802 HewtHI -Packard Journal 59 



Ift 1 




Ha in 


IR1 = 


FlltCHD-cElS 


TINE 




1r lgger 


1) 


InflGO 


CHI 


( 


net! 


INTEOO 


CHJ 


) 




ANRLYI) 


HRGN() 


heiii 


E 


Traces 


ATANM 


REfil ( ) 


flEnS 


• 


DB( ) 


SIGN!) 


mem 






DEM 


SORT ( ) 


nEH4 


• 




DES't) 


sunu 


TRc" 


/ 


Scale 


DFK) 


TOO 


TR3 


CHOP 


DIFfl) 




TRH 


CONU 




d'di ' ) 






rnRR 


Harpers 


EXPJO 




! 


noo 


FFtl) 




n 


us 




fho 




pi 






IDFTO 




T 1 he 




Conf ig 


IFFTO 




FREQ 








POUER 




page 










1 of i 











"BTSF 



SELIEOT 



INSERT 



CLB«HD 



RETURN 



prev 
nenu 



Fig. 16. The microwave transition analyzer indudes ii puwerful 
I race processing system The definition shuvvn here for die display 
trace c an he used in measure deviation ttoni linear frequency 
chirp 

nonobvious) requirement of keeping I he microwave transi- 
lion analyzer abreast of frequency c hanges made on the sig- 
nal generators. Furthermore, because the analyzer has com- 
plete control of the stimulus, network measurements as a 
Function of carrier frequency or power are also possible. 
This added flexibility offers the user a multidimensional 
perspective on the device's operation, along measurement 
axes of time, carrier frequency, or canter power (see Fig. 17). 
One variable is swept while the other two are held fixed. 

An Oscilloscope for the Microwave Engineer. The tools of 
the trade in microwave component design are primarily 
frequency-domain instruments such as spectrum and net- 
work analyzers. Time-domain analysis is not nearly as preva- 
lent at these frequencies as it is at the lower frequencies. 
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Fig. 17. A multidimensional perspectivi is sometimes useful in 
pulsed-RI" device characterization. The microwave transition ana- 
lyzer measures the response of a device as a fiuiction of time. Carrier 
frequency, or carrier power. One variable is swept while the other 
two are held fixed. 



The designers felt that by eliminating some of the road- 
blocks in triggering and sensitivity, the microwave transition 
analyzer had the potential to bring a time-domain perspec- 
tive back to microwave design. The user interface was de- 
signed accordingly, with the microwave engineer in mind. 

One of the simplest and most obv ious changes to a standard 
oscilloscope interface is that display ranges, trigger levels, 
and marker readouts are entered and annotated in clBm as 
well as volts. Also, unlike many oscilloscopes, the channel 
hardware is continuously autoranged and unaffected by the 
display scaling, which is just a mathematical operation on 
the acquired data. If desired, this autoranging feature can he 
disabled. Sensitive internal triggering over the bandwidth of 
the instrument, combined with new features such as holding 
a constant number of cycles on the display, filtering away 
noise instead of averaging, and reliably triggering on even 
very noisy signals with the phase trigger, all work to simplify 
the measurement process. 

1I5ASK Implementation 

Despite considerable attention paid to the interface design, 
some users may still find the controls somewhat intimidat- 
ing, especially those who work in applications outside the 
targeted areas. The goals of measurement flexibility and ease 
of use generally conflict at the design of the user interface. 
To address this concern, the microwave transition analyzer 
allows the user to generate custom, application-specific in- 
terfaces through the internal execution of III' Instrument 
BASK" programs. IBASIC eliminates the need lor an external 
controller by bringing the computer inside the analyzer. Pro- 
grams can be generated and edited by attaching a standard 
11P-I1IL keyboard to the front of the mainframe. Also incor- 
porated into the IIP 70004A mainframe is a memory card 
interface that can be used as a disk drive for the system. 
External disk drives are also supported over the IIP-1B inter- 
face. Specialized trace processing, custom interfaces, multi- 
step procedures, programmable c ontrol of other instru- 
ments — in short, completely customized measurements — 
are possible using the microwave transition analyzer running 
an IBASIC program like the one shown in Fig. 18. 
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Fig. 18. IHASIC programs allow generation of custom user 
interfaces. 
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Frequency Translation as Convolution 



Ar ideal rmxet multiplies the two signals a! its RF and 10 pons to produce the 
signal at the IF pon. as shown in Fig 1 

The irequencv-domain representation of the RF and LO signals is shown in Fig 2 

The convolution ot tne two frequency functions h(fi and Hfi ts the value of the 
integral 



gifl = 



rw kif - «) dx. 



The function kfxl is first frequency-reversed, that is, folded about the dc axis giving 
kl-xl Then, at each evaluation frequency f. k|-x| is shifted by f with respect to 
h(x| The area under the product of the two functions is the convolution output at 
this frequency Fig 3 diagrams the procedure for the output frequency f = f 2 — f 1 - 
The product is a single delta function, the area ot which is aja2/4. This is the 
convolution result at the frequency f = f 2 — fl- 
it is easy to verify that the output will be nonzero only at four values off. f| + f 2 . ft 
- f 2 . -ft + f 2 , and -f| - f 2 At each of these frequencies, the output is aia?/4 This 
result is shown in Rg. 4 This frequency-domain representation is equivalent to 
the sum of two cosine waves, one at frequency (2 - f 1 and the other at fj + fj The 
amplitudes are aja2/2 Using trigonometric identities, it's easy to verify that this 
result is equivalent to a-ja^coslf 1 t)cos(fjt). 
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Fig. 1. Ideal mixei operation 
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Summary 

In addition to bringing the time domain to microwave de- 
sign, the microwave transition analyzer measures harmonic 
distortion using the HPT and provides familar vector network 
analyzer capability when configured with a synthesized signal 
generator. In this respect, the microwave transition analyzer 
is a general-purpose, multidomain tool that can be used to 
link new time-domain measurements with traditional fre- 
quency-domain techniques, particularly in the areas of 
pulsed-RF and nonlinear device characterization. In a single 
instrument, the microwave transition analyzer integrates a 
versatile hardware architecture with very flexible means of 
control. The combination results in an instrument with 
unprecedented measurement diversity. 
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Design Considerations in the 
Microwave Transition Analyzer 



Digital signal processing is used extensively to improve the performance 
of the microwave sampler, the sample-rate synthesizer, and the 
high-speed analog-to-digital converter, and to extract and display input 
signal characteristics in both the time domain and the frequency domain 

by Michael Dethlefsen and John A. Wendler 



The HP 71500A microwave transition analyzer is an MMS 
(Modular Measurement System) instrument. As shown in 
the idealized block diagram. Fig. 1. it consists of the 
IIP 70S20A microwave transition analyzer module and the 
HP 70004A MMS mainframe and color display. For an 
explanation of the capabilities and applications of the 
mic rowave transition analyzer, see the article on page 48. 

The block diagram is relatively straightforward. The two 
input signals are sampled by microwave sample-and-hold 
circuits with an input bandwidth of 40 GHz. The sample rate 
is generated by a low-frequency 10-to-20-MHz synthesizer 
under processor control. The sampled signals are digitized 
by an analog-io-digiial converter (ADC), the digitized outputs 
are processed by the digital signal processor, and the final 
results are displayed on the MMS display by the instrument 
processor, 

The implementation was somewhat more complex than it 
might appear from the block diagram. While microwave 
samplers with bandwidlhs up to 1(1 GHz were generally 
available, they were not designed to be used as saniple-and- 
holrl circuits operating al rates up to "20 MHz. Low-frequency 
synthesizers, while also commonly available, did not have 



the desired phase noise performance. The available high- 
speed ADC's, if used directly on the sampler output, would 
have been the primary noise floor and dynamic range limita- 
tion of the instrument because of their limited resolution. 
Digital signal processing is relied upon heavily to achieve 
and improve much of the basic hardware performance and 
to extract and display the input signals' characteristics in 
both the time and frequency domains. However, the general- 
purpose digital signal processors could not do a significant 
amount of real-time processing at the 20-MHz data rates, so 
a large buffer memory was required between the ADC and 
the digital signal processor. 

This article attempts to explain some of the design consider- 
ations, in both the hardware and Hie firmware, that went 
into the development of the microwave transition analyzer 
block diagram. 

Sampler Operation 

Microwave samplers have been used in RF and microwave 
instrumentation for several decades. 1 They traditionally 
have been the most economical way to obtain the broadest 
frequency coverage with (he smoothes) frequency response. 
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Their noise figure is relatively pour. Their inherent broad- 
band coverage has encouraged their use in frequency acquisi- 
tion and phase-lock loops as well. However, their ability to 
capture the time-domain waveform (or the frequency-domain 
equivalent — simultaneously translating all the harmonics of 
a repetitive waveform) is what made them so suitable for 
the 70820A. 

The basic concept of a microwave sampler is to generate a 
very narrow sampling pulse dial lurns on a series switch 
between the UF inpul signal and die IP circuitry, which is 
mainly a holding capacitor. The amount of time that the 
switch is on establishes the frequency response of the sam- 
pler. If the switch is fully on for 10 ps. the ideal frequency 
response would be sinc( l(H'f), which has a 3-dB bandwidth 
of 4-1 GHz. Although this assumption of a perfectly rectangu- 
lar switch on-resisiance as a function of lime is only an ideal, 
it is a good enough engineering approximation to use here. 
As shown in Fig. 2, the series switch used in Ibis sampler is 
an integrated pair of GaAs diodes. The switching waveform 
is generated by driving a silicon slep recovery diode at a 
variable sample rate between 10 and 20 MHz. The step out- 
put of the slep recovery diode is splii into I wo signals, one 
for each channel. The sampler assembly then shapes and 
differentiates this edge to form a narrow impulse, which 
briefly tunis on the diode switch, allowing some of the RF 
current to flow into the holding capacitor. 

For ideal saniple-and-hold circuit operation, the output volt- 
age should only depend on the input voltage during a single 
sampling instant. Its voltage should not depend on any pre- 
vious samples or how often the samples are taken. There are 
two general techniques to achieve this sample-to-sample 
independence. One is to discharge the holding capacitor 
fully before each sample and measure the amount of charge 
or voltage on the hold capacitor after each sample. The 
other technique is to require that the sample-and-hold circuit 



capacitor charge to 100 percent of the input voltage during 
each sample period. The limitations of using the microwave 
sampler as a high-speed, conventional sample-and-hold cir- 
cuit now begin lo become apparent. At the fast 20-MHz sam- 
ple rates required, it is not possible lo discharge the hold 
capacitor accurately before each sample. On the other hand, 
to attain the required microwave input bandwidth, the sam- 
pling pulse must be so narrow that it is nol possible to 
charge the hold capacitor fully. 

A simplified model of a sample-ajul-hold circuit and the 
equations describing its frequency-domain transfer function 
are shown in Fig. :i. The fraction of the inpul signal that is 
stored on the hold capacitor is referred to as the sampler 
efficiency e, and for this model it can be computed as: 

e = i - e -WRC 
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Fig. 4. Sampler time-domain response for different values of 
sampler efficiency e and hold efficiency H. 

10096 efficiency, e = 1, would require thai Hie sampler on- 
linie be several EC time constants long. Inn this would mean 
an excessively small input bandwidth, as shown by the Grj- 
portion of the sample-and-hold circuit frequency response 
equation in Fig. 3. Most microwave samplers have relatively- 
low voltage transfer efficiencies, usually significantly less 
than 10%. With this low sampling efficiency, the resultant 
voltage on the hold capacitor is a weighted combination of 
the input voltage from many samples. Sample-to-sample 
independence is not achieved. 

An ideal saniple-and-hold circuit also holds its sampled volt- 
age indefinitely until either a reset or the next sample occurs. 
The voltage droop from one sample to the next is character- 
ized by the hold efficiency B, which can be computed as: 

B = e -'« /K i' ( ', 

where t s is the sampling period and U,, is the sample-and- 
hold circuits load resistance as defined in Fig. -'5. 1(!<)% hold 
efficiency means no droop and an infinite load impedance. 
Fig. 1 shows the lime-doiuaiu results of sampling a pulse 
waveform with a sample-and-hold circuit that has ideal char- 
acteristics, with reduced sampler efficiency, and with re- 
duced hold efficiency. Fig. 5 plots the Off portion of the 
sample-and-hold circuil's frequency response equation for 
sampler efficiencies of 10096, 10%, and 1%. and for hold efil 
ciencies or 9096 and 10096. For low sampler efficiencies like 
those normally encountered in microwave samplers, the 
plots in Fig. 5 look very much like a single-pole, low-pass 
filter. Thi' equations for < <lo indeed simplify and con- 
verge, in this case, to a single-pole filler. The efficiency 
equations become: 

e = Um 

B = 1 - t s /R,,C. 

The original model then becomes the very commonly used 
model shown in Fig. t>. The sampler is simply replaced by its 
lime averaged impedance Kls/I ()n - 

This characterization of the sampler model points out the 
main difficulties of using a microwave sampler as a sample- 
and-hold circuit The IF output voltage is low-pass filtered 
and represents an average of many samples of the input 
voltage. In addition, if the hold efficiency is not very close to 
1, even the low-frequency gain will vary with the sampling 



frequency and the sampler efficiency' as shown in Fig. -5. To 
solve (His latter problem, the HP 70S20A microwave transi- 
tion analyzer module uses a very high-ini|jedancc buffer on 
the output of the sampler and provides a positive feedback 
bootstrap voltage to remove the low-frequency loading 
effects of the current biasing resistors as shown in Fig, 2. 
Operating with this high load impedance has the additional 
benefit of minimizing the sampler compression at high input 
levels since very little signal current has to flow through the 
sampler diodes. In addition, since the sampler diodes are 
effectively current biased instead of voltage biased, their 
sensitivity to temperature variations is considerably reduced 

The problems created by the sampler low-pass filter effect 
are more difficult to solve. As the sampling frequency is var- 
ied, the Current bias is changed by the processor to keep the 
sampler on-time t„ n constant. This is required so that the KF 
frequency response does not vary noticeably with sampling 
frequency. However, since the sampler time constant is pro- 
portional to t„ n /t s , the IF bandwidth now varies with sam- 
pling frequency. To solve this problem a programmable zero 
was added following the IF buffer amplifier (see Fig. 7). 
During the IF calibration process, the sample-and-hold cir- 
cuit low-pass pole is measured as a function of the sampling 
frequency. Whenever the sampling frequency is changed, the 
programmable-zero amplifier is adjusted to cancel the effort 
of the sampler pole. 

Another challenge encountered when using a microwave 
sampler as a saniple-and-hold circuit is its fcedthrough capac- 
itance. A capacitance as low as 50 feintofarads between the 
HF input and IF output will cause significant errors in the 
expected operation of the microwave sampler. Signals be- 
low 10 MHz will directly couple into the IF even when the 
sampler is supposed to be off. To cancel this effect, the input 
signal is lapped off before the sampler diodes, inverted, and 
capacilively summed back into the IF signal. 

The [F Output of the sampler is ac coupled. When the Instru- 
ment is dc coupled, the dc component is restored by picking 
it off before the sampler diodes and summing it back in at 
the IF buffer stage. The crossover frequency is about :? Hz. 




l, = Vt, 



Fig. 5. Sampler ik frequency response ten different values of 

sampler efficiency e ami hold efficiency U. 
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Fig. 6. Simplified sampler model. 
IF and ADC Operation 

Now thai the signal has been sampled and the sampler polo 
effect has been canceled, the IF signal can be processed and 
digitized. The IF processing block diagram is shown in Fig. 7. 
The ADC used in I he HP 70820A is a 10-bit device, operating 
at the same frequency as the input sampler. This 10-bit reso- 
lution does not provide enough dynamic range for many of 
the measurements performed by the microwave transit ion 
analyzer. For example, network analysis measurements can 
be performed over a greater-than-100-dB range and time- 
domain waveforms of 1 mV full scale can be captured with- 
out requiring trace-to-trace averaging. To achieve this dy- 
namic range improvement, step gains are placed in the IF 
signal path. Up to 60 dB of gain in 0-dB steps can be switched 
in. either ant oranged or manually controlled by the user. 
This means that even low-level signals can use the full range 
and accuracy of the ADC. To allow gain to be used even in 
the presence of a large dc signal, a dc offset DAC is added 
ahead of the step gains as shown in Fig. 7. This allows up to 
±120 mV of offset to be applied to the IF signal before the 
step gains. The dc offset capability does not affect the al- 
lowed input signal range. It must be kept less than 420 mV 
peak to avoid sampler compression. 

The total noise present in the IF may mask the input signal 
and limit the amount of step gain that can be used without 
overranging the ADC. This noise is there because the sam- 
pler translates the entire 40-GHz bandwidth into the IF fre- 
quency range. The programmable-zero amplifier also adds a 
lot of high-frequency amplification to the sampler and the IF 
buffer noise floor. All of this noise needs to be minimized. Il 
is also highly desirable to remove any harmonics of the sam- 
pling LO signal and signals centered around them. To solve 
these problems, swilchable low-pass IF filters are used. 
These include a 10-MHz Biter for sampling rates between 14 



and 20 MHz and a 7-MHz filler for sampling rates less than 
14 MHz. In adtlition. a 100-kHz analog noise filter can be 
switched in to provide a greater-ihan-20-dB reduction in 
total noise. Since this noise filtering is done in real lime, il 
provides faster signal-to-noise ratio improvemenl lhan the 
digital signal processor-based alternatives. 

As described ill the article on page 48. Ihe IF signal is a lime- 
scaled version of the original RF signal when Ihe instrument 
is operating in Ihe standard, repetitive sampling mode. 
Therefore, triggering Information can be obtained from the 
IF signal. Since the signal is al a much lower frequency and 
is potentially amplified and Tillered, the trigger circuitry is 
cheaper to implement and more accurate lhan a trigger cir- 
cuit operating directly on Ihe microwave signals. This allows 
the microwave transition analyzer to trigger internally on 
very low-level periodic signals anyw here in its microwave 
frequency range. 

Once the IF signal has been filtered, offset, and amplified, it 
is ready to be digitized. The ADC is a commercially avail- 
able, two-pass, 10-l>ii ADC and the required external sample- 
and-hold circuit is Implemented with a discrete design. The 
sample-and-hold circuit and ADC are driven at the same 
frequency as the microwave input sampler. The digitized 
signal is stored into the 256K-samplc ADC memory buffer 
for further digital signal processing. 

IF Corrections 

Fig. 8 shows a representation of the spectrum of Ihe analog 
IF signal for a sample rate of f s = l/t s . The ideal sampling 
operation creates a spectrum dial is replicated every f s so 
the spectral component at {■> = f s - f | is the complex conju- 
gate of the ideal spectral component at fj. The IF proces- 
sing, including the hold operation of Ihe microwave input 
sampler and the low -pass filters, provides a different 
amount of attenuation and phase shift at Ihe IF frequency f> 
lhan at frequency fj. This is signified by the G(f) transfer 
function in Fig. 8. When the ADC sample-and-hold circuit 
resamples Ihe IF signal. Ihe spectral component al will be 
aliased or folded onto the same frequency as (j. II is nol pos- 
sible lo build a perfect anti-aliasing tiller thai will totally 
eliminate f>. even at a fixed sample frequency of 20 MHz. 
and in 'his application, Where the sample rate is continuously 
variable between 10 and 20 MHz, there will be significant 
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Fig. 8. Sppclmm folding in the mirrmvavf transition analyzer 

aliasing. However, since the filtered IF signal was originally 
a sampled signal, the relationship between the original 
aliased spectrum and the unaliased spectrum is known: 

v 2 = v,*. 

Therefore, the original spectrum can be computed if the 
folded IF response (G(f\) + G*(f s - fj}) can be determined. 
The folded frequency response varies with f s . and f s can be 
any value between 10 and 20 MHz. Therefore, the IF cannot 
realistically be calibrated, just by measuring I he folded IF 
response, since there are an almost unlimited number of 
different responses possible. Instead, the unfolded frequen- 
cy response (1(f) must lie determined and then the folded 
response can be computed based on the present value of f s . 
Determining the folded IF response is the major requirement 
for the digital signal processor-based IF corrections in the 
microwave transition analyzer. 

Many things contribute to the overall IF frequency response. 
In addition to the flatness of the IK buffer amplifier, the 
programmable-zero amplifier, and any nonideal cancellation 
of the sampler pole, all possible combinations of analog fil- 
ters and step gains must be characterized. For example, the 
relatively high-order fillers may have an amplitude response 
flatness of ±2 dB and some very significant group delay vari- 
ation which creates considerable ringing in their step re- 
sponse. To measure these, the microwave transition analyz- 
er generates a calibration signal. The calibration signal is a 
precisely known square wave that is connected by the user 
to the input port The frequency and amplitude of the cal- 
ibration signal are adjusted and varied as required during 
the IF calibration process. This calibration signal is only 
used for IF calibration and verification. The rise and fall 
lime requirements on the calibration signal are governed by 
the requirement that it settle in less than 50 ns. so it is not 
useful for verifying or calibrating the RF frequency response 
of the input. 

The IF frequency response must be measured in an alias- 
ing fashion and at frequencies higher than HI MHz. This 
cannot be done with just a 20-MHz maximum sample rale. 
The exclusive-OR control shown in Fig. 7, which Inverts and 



delays the ADC clock, helps solve this problem. By first 
measuring the calibration signal with a normal 20-MHz clock, 
and then remeasuring the same signal with the inverted 
clock, which delays the ADC sample by 25 ns. an effective 
40-MHz sample rate is achieved after the two measurements 
are interleaved- In this way, the frequency responses, both 
magnitude and phase, of the IF path, the step gams, and the 
switched filters are all determined In some cases the mea- 
sured data is used directly in the correction process. In other 
cases, such as for the step gains, better results are achieved 
by fitting the measured data to a model and then computing 
the extrapolated frequency response from the model. 

The other critical parameter that must lie included in the IF 
frequency response is the delay between the microwave 
input sampler and the ADC sample-and-hold circuit. This 
must include both the IF signal delay and the delay in the LO 
clock paths. Since this delay is not constant with sample 
frequency, it must be characterized as a function of the sam- 
ple frequency. A significant portion of the IF calibration time 
is spent doing this characterization. This involves measuring 
the group delay of the harmonics of the calibration signal at 
different Sample frequencies. 

Once the unfolded frequency response and the delay have 
been measured, the folded frequency response can be com- 
puted for a given sample frequency. However, since the V| 
and Vjj spectral components can have very similar ampli- 
tudes, it may turtl out that the folded frequency response has 
a very deep null in it. depending on the phase relationships. 
An excessively deep null cannot be properly corrected, for 
both noise and stability reasons. When this occurs, the firm- 
ware in the microwave transition analyzer must change the 
delay relationship between the IF signal and the ADC clock. 
This can be done with either the ADC clock invert/delay 
control or by using a different 20-MHz analog filler in the 
signal path. The linn ware determines which of the possible 
combinations results In (he best possible folded frequency 
response. 

Once the IF calibration process has been completed, the 
data is stored in battery backed-up RAM. Whenever the sam- 
ple frequency or IF gain is changed, the microwave transi- 
tion analyzer firmware recomputes the folded frequency 
response of the IF. This folded response is then inverted and 
applied to the digitized input data using either an FFT (fast 
Fourier transform ) operation or a 04-poinl FIR ( finite impulse 
response) digital filtering operation, depending on the mea- 
surement mode. The result is thai the IF looks as if it has a 
fiat response all the way to the Nyquisl frequency (f./2). 
Therefore, the microwave sampler appears to have the ideal 
impulse and step response expected of a true sample-and- 
hold circuit. 

Sample Rate Synthesizer 

The requirements on the sample-rate synthesizer in the 
microwave transition analyzer are quite stringent. Not only 
niiisl it have a frequency resolution less than 0.001 llz over a 
lO-lo-20-MIIz frequency range, but it must also be able to 
phase-lock to a common 10-MHz reference and be capable 
of shifting the phase of the synthesized output with less than 
0.< Mil -degree resolution. Fortunately, this type of source, 
using fraclioual-N synthesis techniques,- had been used in 
earlier III* instruments and could be efficiently leveraged. 
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The most stringent requirement lor the source was its jilier. 
or equivalent phase noise, but the available Implementations 
had inadequate performance. Boih the close-in and the 
broadband phase noise of the synthesizer are important For 
example, just based on the maximum slope of a full-scale 
40-GIlz sine wave, jitter of 7 femtoseconds on the sampler 
LO signal generates additional noise greater than one least- 
significant bit of the ADC. Since the fundamental of the RF 
waveforms can be mixed to as low as 100 II/. in the IF, mini- 
mizing the close-in noise and spurious components of the 
sample-rale synthesizer is critical to avoiding low-frequency 
perturbations and distortion of the digitized signal. 

To improve the basic performance of the available 
fractionai-N synthesizers while still lev eraging much of the 
previous engineering effort and available integrated circuits, 
a translate loop was added to the normal synthesizer block 
diagram. As seen in Fig. !>, instead of having the loop oscilla- 
tor operate directly over the normal .'!(i-to-"i(i-Mllz band, a 
420-to-l-lO-MIIz oscillator is mixed with a 390-MHz reference 
oscillator. The mixer output. "iO lu ">0 MHz. is the input to the 
leveraged fraclional-N assembly, which does the fractional 
division, phase detection, and interpolated phase correction, 
and generates the tuning voltage to lock the 440-MHz oscilla- 
tor. A second output of the 410 .MII/. oscillator is fed to a 
programmable integer divider to generate the l()-to-20-MHz 
output. 

There was no requirement for this synthesizer to sweep con- 
tinuously over the 10-to-20-MIIz range. This translate-and- 
divide-down block diagram allows the performance of the 
overall synthesizer to be improved from the original design 
by a factor equal to the integer divide number, or more than 
2(3 dB. To improve the broadband phase noise further, a 
200-kllz-wide bandpass filter is switched in just before the 
step recovery diode driver whenever the synthesizer is With- 
in the 10.S-!o-20-MHz frequency range. In the majority of the 
measurement modes, the synthesizer is set very close to 20 
MHz. so (his bandpass filler is normally used. While it was 
not possible to achieve the 7-fs performance number, this 



Fig. 9. Block diagram of the 
10-1 0-21) MHz sample rate synthe- 
sizer, API stands for analog iiluise 

Interpolation. 

combination of improvements reduces the jitter contribution 
of the synthesizer to less than 1 ps. 

RF Filtering 

Because the microwave transition analyzer digitizes wave- 
forms with a continuous and extremely precise time axis, it 
becomes feasible to apply digital filtering functions to these 
waveforms. These filters can be used to simulate the adding 
of a hardware filter to the system, to improve the signal-to- 
noise performance, to remove undesired harmonics and 
spurious frequency components, and to Compensate for non- 
ideal microwave frequency response effects in the RF cir- 
cuitry, cabling, probes, and test fixtures, which inevitably 
degrade the system bandwidth This ability to correct for RF 
frequency response roll-off is also used within the instru- 
ment to flatten the frequency response of both the samplers 
and the internal RF cabling to 40 GHz. 

Two fillers can be defined by the user, one for each of the 
two input channels. These filters are specified by defining 
the magnitude and phase response at up to 128 arbitrarily 
spaced frequency points. The type of interpolation to be 
used between these frequencies can be specified as flat, 
linear, or logarithmic. These user-defined filters are com- 
bined with the instrument's own RF correction data to gen- 
erate the Composite filter function that is applied to the digi- 
tized signal. Regardless of whether the sampler is being 
used for frequency translation or frequency compression or 
a combination of the two, there is a unique mapping be- 
tween the input RF frequency and the IF frequency. This 
means that the desired RF filtering can indeed be performed 
by scaling and translating the tillers' frequency axis, based 
on the current time span and carrier frequency, into the IF 
band and performing the filtering on the digitized IF signal. 

There are some modes of sampler operation in which the RF 
waveform is not replicated in the IF. so there is no unique 
RF-to-IF frequency mapping and RF filtering cannot be per- 
formed. An example of this mode of operation would be 
when triggering on the clock frequency while sampling a 
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Fig. 10. An example of a measurement with user filter corrections. 
Tip/ frequency response of a cable fixture was measured (bottom 
trace), stored, and used to correc t a measurement of an H00-ps 
pulse that was made using the fixture. The corrected I race mea- 
sured with the fixture is almost identical lo the ideal (race mea- 
sured without the fixture Because the Ideal and corrected traces 
are alfllQSt identical, they are indistinguishable in this figure. 

random data sequence to create an eye diagram. User filter- 
ing, including I he internal RF corrections to 111 (illz. is noi 
valid in this mode so the feature must be turned off. If. how- 
ever, the data sequence is actually a pseudorandom data 
sequence and the sample rale of the microwave transition 
analyzer is adjusted lo correspond lo the pattern repetition 
rate instead of the clock rate, then the RF waveform is repli- 
cated in the IF. mid UK filtering and corrections can lie per- 
formed, even while triggering on the clock lo make eye 
diagram measurements. 

The user filler and correction dala can be generated in sev - 
eral ways. Direct entry of values is one alternative thai is 
useful for simple, reel angular fillers. The frequency -domain 
dala for the RF filler can also be generated from any of the 
four traces. This means that mathematical fillers can be de- 
fined using the built-in trace math and stored to I he RF filler. 
More important, it means thai measurements can be used lo 
Create the RF filler or Correction data. For example, the 
microwave transition analyzer, in conjunction w ith an ap- 
propriate source, can be used lo measure a transfer function 
of a microwave test fixture. This transfer funct ion can be 
stored lo the user correction (able, and the inverse of ibis 
transfer function can then be used as the RF filler lo be ap- 
plied to the lime-domain dala. This filtering ( decompilation) 
removes the frequency response effect of the lesl fixture 
from the time-domain waveform of interest The transfer 
function measurement can be done in frequency sweep 
mode with a CVV source stepped over the frequency range of 
interest like a conventional network analyzer, or the transfer 
(unctton can be measured with a wide-baiuKvidlh step or 
impulse source. 

An example of applying Ihe user correction filler is shown in 
Fig. 10. Firsl the frequency response transfer (unction of a 
cable fixture was determined by measuring ;i 100-ps pulse 
both before and afler it went through the cable fixture. The 
FFT of these two pulse trains was computed to determine 
their frequency spectrums. The ratio of these two spec! rums 



was taken and stored to the user correction filter as the 
cable fixture's frequency response. This is shown on the 
bottom trace in Fig. 10 out to a frequency of 8 GHz. A test 
pulse of of 800 ps was then used. The upper raw trace shows 
the pulse distortion caused by Ihe cable fixture. After user 
corrections were turned on. the corrected trace was gener- 
ated, which lies almost directly on the ideal trace. The ideal 
trace was established by measuring the pulse directly out of 
the puis*' generator before it was connected to the cable 
fixiure. The time-domain traces are showing a half cycle of a 
200-MHz pulse train, 

There are some limitations on the ability of the mic rowave 
transition analyzer to apply RF filtering and correction to 
lime-domain waveforms. First, the IF waveform must be a 
valid representation of the RF waveform. If there are non- 
hannonically related, spurious, or random signals present, 
they will be mixed into the IF but will not appear at the cor- 
rect frequencies, so incorrect filter values will be applied to 
them. Second, the signal must be Sampled with fine enough 
equivalent time resolution to avoid aliasing any significant 
harmonics or sidebands. This is just the Nyquist criterion, 
which says that a signal must be sampled at a rate greater 
than twice its single-sided bandwidth. This applies to both 
real-time, single-shot sampling and repetitive, equivalent 
time sampling. Any aliased components will appear at the 
incorrect frequencies and be improperly filtered. 

Third, because limited lime records are captured and pro- 
cessed with the FFT, totally arbitrary filter shapes cannot, in 
general, be precisely accommodated. For example, a filter 
shape with a 2-us transient response would require that 2 ps 
of an arbitrary input be. digit ized to generate even the first 
OUtpU) point A desired time resolution of I ps would require 
two million dala samples and a digital filter with effectively 
two million coefficient taps. There are two methods avail- 
able to minimize this limitation. If an integer number of 
cycles of the input are used in Ihe FFT processing, then arbi- 
trary filter shapes can be precisely handled. The circular 
COhVOlutiOn performed by the FFT is, in (his case, exactly 
equivalent to the desired linear convolution. To make this 
more practical lo the user, a cycles mode is available in 
which Ihe lime span can be set in terms of cycles of the fun- 
damental instead of seconds per division. This automatically 

tracks the fundamental frequency as ii is changed The micro- 
wave transition analyzer oversweeps Ihe lime-domain span 
up In the next largest power-of-lwo trace size. For example, 
if a 0.5-cyele lime span is specified with a trace poinl size of 
512. then one full cycle of the waveform is digitized and a 
1024-poinl FFT is used. 

The second method of minimizing the effect of limited lime 
records is lo make sure thai Ihe filler's transient response is 
shorter than the minimum displayed lime span to be used. If 
the waveform used in the FFT does not contain an integer 
number of signal periods, (here will potentially be edge ef- 
fects because of ihe combination of (he discontinuity at the 
edges of the lime record and the filler's transient response. 
Since Ihe instrument oversweeps up lo a factor of two, the 
edge effects w ill not be part of Ihe displayed wav eform as 
long as Ihe filler has a transient response shinier than the 
displayed time span. 
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A fourth limitation on the ability of i hi* microwave transition 
analyzer to apply RF filtering and correction is thai decon- 
volution cannot he performed over a w ide dynamic range. 
For example, if the test fixture has an tipper frequency roll- 
off ora narrowband notch of 50dB. correcting for this would 
require that the microwave transition analyzer effectively 
apply 50 dB of gain at these frequencies. This much gain on 
the noise components creates an excessively noisy and un- 
stable waveform trace. In general. 20 to 30 dB is about the 
largest amount of frequency dependent amplification that 
can be used while maintaining an acceptable waveform with 
a reasonable amount of averaging and reasonable stability in 
the test fixture. When creating the transfer function to be 
used in the deconvolution, the attenuation should be rolled 
off once the transfer function has dropped below the accept- 
able limit. This also effectively low-pass filters the signal at 
frequencies above which deconvolution can no longer be 
done. This is seen in the last division of the user correction 
trace shown in Fig. 10. where the frequency response is be- 
ing tapered from -36 dB to +20 dB at 10 (ill/,. Keeping the 
value of -35 dB to the default 100-GIIz maximum frequency 
would have resulted in excessive noise because of the +35 
dB of broadband gain that this would have created. 

Analytic Signal 

Many of the primary applications for the microwave transi- 
tion analyzer result from its built-in capability to easily dis- 
play the instantaneous magnitude and phase envelope of the 
input signal. This capability is implemented by creating the 
quadrature function using the llilbeil transform. This quad- 
rature function is combined with the original data to form a 
complex-valued representation of the waveform called the 
analytic Signal. Just as complex-valued phasot representa- 
tions simplify the analysis of linear circuits, the analytic sig- 
nal simplifies the manipulation and analysis of modulated 
waveforms. 

Assume a signal can be mathematically expressed as 

x(t) = a(l)cos(ui,.t + e|>(t)), 

where iu,. is the carrier frequency and al l ) and <|i(t ) are the 
amplitude and phase modulation functions. 

Now create the complex function. 

= X(l) - .jX,„(l). 

where X|,j(t) is the Hilbert transform of x(t ). The llilben 
transform is defined as a convolution of the the signal with 
-l/.tt. The frequency-domain relationship is simply: 

X,„(f) = jX(f)sign(f). 
where sign(f) = -1 for f < 0, 0 for r= 0, and 1 for f > 0. Thus, 

SjjjjQ = X(f)(l + sign(f)( 
= 2X(f)forf > 0 
= X(f)forf = 0 
= Oforf < 0. 

This is simplv the positive spectrum of xll ). 

If the modulation bandwidth is less than the earner frequency 
(i.e.. the modulation spectrum doesn't wrap around del. then 

x.,(t) = a(t)eO'.'"i«"i 



and all ) and (|>(l ) can be simply calculated from the 
magnitude and phase of the analytic signal x a (t ): 

alt) = /(x(t)- + x„,(t)-) 

and 

cp(t) = - tan-'fx^Q/xO.)) - M, 

Another way to view the llilben transform is as a phase 
shifter that shifts the phase of each input frequency compo- 
nent by III) degrees, leaving the magnitude unaffected. The 
resulting signal is said to be in phase quadrature with Un- 
original. This is sometimes done with analog phase shifters 
in radar and receiver systems. Very accurate, wideband re- 
sults become much easier to achieve, however, with digital 
signal processing, using either the FFT as shown above, or 
time-domain FIR fillers. 

The analytic signal representation is particularly useful in 
the measurement of pulsed RF signals. In these applications 
il is often the characteristics of the magnitude or phase as a 
function of time that are of interest. These features of the 
signal can be obtained by simply converting the analytic 
representation to polar formal and displaying the desired 
quantity. Traces of phase as a function of time can be numer- 
ically differentiated to display frequency as a function of time. 
A linear slope corresponding to the carrier frequency can be 
mathematically removed leaving a display of the carrier's 
phase modulation as a function of time. As described here, 
these are single-channel measurements where the carrier 
phase is measured relative to the fixed-frequency sampling 
pulse. Measuring the phase with respect to a CW reference 
is also possible, using both input channels. 

Two-channel operation suggests another valuable use of the 
analytic representation: vecior normalization of traces. 
Many times it is desired to measure the magnitude and 
phase response of a particular device under a lime-varying 
stimulus, such as pulsed RF. In this case, a two-channel mea- 
surement is needed in which I he time response at the output 
of the dev ice is div ided ( in vector fashion ) by the response 
at the input. Also, to support the measurements typically 
found in conventional network analyzer systems, a complex 
(vector) representation of trace data is mandatory. 

Since the llilben transform is a filtering process, it has the 
same limitations and constraints as previously discussed for 
RF filtering. In addition, il has the constraint that the signal 
must correspond lo the basic model of a single carrier fre- 
quency with modulation sidebands. For example, baseband 
signals with a fundamental and many harmonies do not 
meet this crilerion. and the analytic operator has little, if 
any, useful meaning. The user can disable the analytic opera- 
tor iu this mode to achieve some increased perfonnance 
speed. The llilben transform performs best if the carrier is 
located in the center of the IF bandwidth. This provides the 
maximum amount of double-sided Modulation bandwidth, 
and keeps the earner the maximum distance from dc or the 
Nyquisi frequency where inaccuracies in the llilben trans- 
form are the greatest. The internal implementation of the 
llilben transform generally uses the positive-side FFT tech- 
nique, with some additional enhancements using windowing 
and unwindowing operations lo minimize the time record 
edge discontinuities. 
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Sampling at Slower Rates 

As mentioned earlier, the sampling rate synthesizer operates 
between 1(1 and 20 MHz. Normally, the sampling rate must 
be set very close to the input signal's fundamental frequency 
or pulse repetition frequency Of a subharmonic [hereof. This 
means thai signal frequencies less than 10 MHz cannot be 
acquired in the normal manner. If the hardware sampling 
rate is set to a multiple of the desired rate, then simply keep- 
ing one out of every N points would result in the desired 
sampling rate. I "nfortunately. complications arise for trigger- 
ing and providing IF correction. Because more than one 
sample is taken during each period of the input signal, the IF 
signal presented to the ADC is not an accurate replica of the 
input signal, with or without IF correction. For this reason, 
triggering 00 the IF signal is no longer adequate for proper 
operation. What is required is a digital triggering operation 
using only the samples corresponding to the final (decimated) 
sampling rate. To correct the IF response and ensure that 
the retained sample is an accurate measure of the input sig- 
nal voltage, the influence of the samples leading up to the 
desired one needs to be removed. This can only be achieved 
by processing the original samples obtained at the hardware 
sampling rale and correcting the desired sample before 
discarding the remaining N-l samples. 

Many samples may haw to be processed before a software 
I rigger is detected. Consequently, the processing Involved i" 
applying IF corrections to the retained samples needs lo be 
done in real time, that is, the correction process needs to 
operate in parallel with the data collection at a rate that is 
sustainable over an indefinite period. This is accomplished 
by designing the ADC memory to he a dual-ported circular 
huffer so thai one segment Of memory can be worked on 
while another is being written to hy the ADC. As samples 
are collected at the I0-Io-20-Mllz rate in another part of 
memory, a finite impulse response (FIR) IF correction filler 
of up t0 laps is applied lo the block of samples just col- 
lected and a single corrected output sample is produced. 
The digital signal processor is able to produce corrected 
samples at a maximum rale of about 10 kll/.. This then 
becomes the maximum sampling rale in Ihe new mode of 
Operation. The minimum sampling rale is 1 II/.. 

Input signals with a fundamental repetition frequency less 
than 10 kHz are sampled once per cycle. The sample rate 



synthesizer is set somewhere between 10 and 20 MHz. N is 
determined, and 1 of N hardware samples are corrected and 
retained The process is the same for input repetition fre- 
quencies between 10 kHz and 10 MHz except that multiple 
input periods occur between each retained sample, keeping 
the output rate less than 10 kHz. 

Conclusion 

By combining and enhancing the basic analog and digital 
hardware blocks with the flexibility of digital signal process- 
ing, the HP 70820A microwave transition analyzer team was 
able to implement a fundamentally simple microwave data 
acquisition instrument that is capable of making a wide vari- 
ety of time-domain and frequency -domain measurements on 
mic rowave signals and components. Not only does this pro- 
side new versatility previously unavailable in a single instru- 
ment on both CW and complex time-varying signals, but it 
also provides new functionality to the microwave designer — 
for example, in looking at extremely fast transitions on 
periodically pulsed signals. 
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A Visual Engineering Environment for 
Test Software Development 

Software development for computer-automated testing is dramatically 
eased by HP VEE, which allows a problem to be expressed on the 
computer using the conceptual model most common to the technical user: 
the block diagram. 

by Douglas C". Beethe and William L. Hunt 



For many years, the cost of developing computer-automated 
lesting software lias grown while the cost of the computer 
anil instrumentation equipment required lo run tests has 
dropped significantly. Today, in many lest systems, the hard- 
ware costs represent less than 25";, of the total cosl of the 
system and software costs consume the oilier 75%. Ill' VEE 
was designed lo dramatically reduce lesi software develop- 
ment cosls by allowing the lesl lo he expressed on the com 
puler using I he eoneeplual model mosl coinmoii lo the lech 
nical user: the hlock diagram. This article will provide a 
general overview of the developmenl of HP VEE, its feature 
sei. anil how il applies the concept of the executable block 
diagram. Further del ails of the architecture of HP VEE can 
be found in I he art icles on pages 78 and 81. 

There was a time when business and finance people dreaded 
using a computer because it meant an extended qneslion- 
and-answer session with a primitive mainframe application 
being displayed on a dumb terminal. Even after the first per- 
sonal Computers were introduced, very little changed, since 
the existing applications were simply rewritten CO run on 
them. When the electronic spreadsheet was developed, busi- 
ness users could finally interact with the Computer on their 
own terms, expressing problems in the ledger language they 
understood. 



The technical community was left out Of this slory. not be- 
cause the personal computer was incapable of meeting 
many of their needs, bul because their problems could sel- 
dom be expressed well in the rows and columns of a ledger. 
Their only options, therefore, were lo continue lo work wilh 
the quest ion-and-answer style applications of the past, or to 
write special-purpose programs in a traditional programming 
language such as Pascal, (". or BASK'. 

Technical people often find il difficult lo discuss technical 
issues without drawing block diagrams on while boards, 
notebooks, lunch napkins, or anything else at hand. This 
begins al the university where they are taught lo model vari- 
ous phenomena by expressing the basic problem in the form 
of a block diagram. These block diagrams usually consist of 
objects or processes that interact with other objects or pro- 
cesses in a predictable manner. Sometimes the nature of the 
interactions is well-known and many times these interactions 
must be determined experimentally, but in nearly all cases 
the common language of expression is the block diagram. 

Unfortunately, the task of translating the block diagram on 
Ihi' lunch napkin into some unintelligible computer language 
is so difficult that mosl technical people simply cannot ex- 
tract real value from a computer. Slaying up on the learning 
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curve of their own problem domain is a sufficient challenge 
that embracing a whole new learning curve (programming) 
just to translate problems for the computer's !>enefit hardly 
seems worth the effort. While it is true that many wonderful 
solutions to certain kinds of problems have been generated 
over the years, most of the potential usefulness of comput- 
ers has never been realized. In many cases, a good calcula- 
tor is still the best bet because it makes a manual solution 
relatively easy to compute. 

What is HP \ EE? 

HI' VEE. Hewlett-Packard's visual engineering environment, 
is a software tuol that allows users to create solutions by 
linking visual objects (icons) into block diagrams, rather 
than by using traditional textual programming statements. 
IIP VEE provides objects for data collection, analysis, and 
presentation, in addition lo objects and features for data 
storage, flow, modularity, debugging, documenting, and 
creating graphical user interfaces. The objects work to- 
gether in the form of an interconnected network or block 
diagram constructed by the user lo represent the problem at 
hand. The user selects the necessary objects from the menu, 
links them in the manner that represents how data flows 
from one object to another, and then executes the resulting 
block diagram. No translation to some other language. No 
other intermediate step. 

To understand HP VEE better, consider a simple graphical 
program to draw a circle. By connecting a loop box. two 



math boxes (sin and cos), and a graph, tliis simple program 
can be buill in less than one minute (Fig. I). Although this is 
not a difficult task using a traditional language that has sup- 
port for graphics, it is still likely thai it will be quicker to 
develop it using HP VEE. 

HP VEE eases the complexity of data typing by providing 
objects tliat can generate and interpret a variety of data 
types in a number of shapes. For example, the virtual func- 
tion generator object generates a waveform data type, which 
is just an array of real numbers plus the time-base informa- 
tion. It can be displayed on a graph simply by connecting its 
output to the graph object. If its output is connected to a 
special graph object called a MagSpec (magnitude spectrum ) 
graph, an automatic FFT (fast Fourier transform) is per- 
formed on die waveform (Fig. 2). By connecting a noise gen- 
erator through an add box. random noise can be injected into 
this virtual signal (Fig. 3). If we had preferred to add a dc 
offset to this virtual signal, we could have used a constant 
box instead of the noise generator. 

User panels allow HP VEE programs to be built with ad- 
vanced graphical user interfaces. They also allow the imple- 
mentation details to be hidden from the end user. To com- 
plete our waveform application, we can add the slider and 
the graph lo the user panel (Fig. 4). We can adjust the pre- 
sentation of this panel by stretching or mov ing the panel 
elements as required for our application. 
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This is just a trivial overview of Ihe basic concept behind 
III' VEE. i )ther major features not covered include objects 
for sending data to and from files, data translation and con- 
version, advanced math capabilities, and data display func- 
tions. HP VEE actually consists of I wo products. HP VEE- 
Engine is for (he analysis and presentation of data gathered 
from files or programs or generated malhemalically. HP 
VEE-Test is a supersei of IIP VEE-Engine and adds objects 
and capabilities for device I/O and instrument control. 

Development Philosophy 

The team's goal for IIP VEE was a new programming para- 
digm targeted not only at Ihe casual user, but also at the 
advanced user solving very complex problems. One simple 
approach would have been to assign an icon to each stale 
ment in a traditional language and present it to the user in a 
graphical cnvironmcnl. The user would simply create icons 
(statements) and connect them in a structure similar to a 
flowchart. However, such a system would be harder to use 
than a traditional language, since the graphical program 
would require more display space than the older textual 
representation and would be more difficult lo create, 
maintain, and modify. This would actually have been a step 
backward. 

We decided that a genuine breakthrough in productivity 
could only be achieved if we moved to a higher level of ab- 
straction to more closely model the user's problem. We 
therefore chose to allow users to express their problems as 



executable block diagrams in which each block contains the 
functionality of many traditional program Statements. Many 
elements in HP VEE provide functionality that would require 
entire routines or libraries if the equivalent functionality 
were implemented using a traditional language. When users 
can work with larger building blocks, they are freed from 
Worrying about small programming details. 

Consider the task of writing data to a file. Most current pro- 
gramming languages require separate statements for Opening 
the file, writing the data, and closing the file. Il would have 
been relatively easy to create a file open object, a file write 
object, and a file close object in IIP VEE. Such an approach 
would have required at least three objecis and their associ- 
ated connections for even the simplest operation. Instead, 
we created a single object that handles the open and close 
steps automatically, and also allows all of the Intermediate 
data operations lo be handled in the same box. This single 
To File box supports the block diagram metaphor because the 
user's original block diagram would not include Open and 
close sleps (unless lliis user is also a computer programmer), 
it would only have a box labeled "Append I his measurement 
to the data file." The open and close steps arc programming 
details that are requited by traditional programming languages 
but are not part of the original problem. 

Or, consider the task of evaluating mathematical expres- 
sions, hi some common dataflow solutions, a simple opera- 
lion such as 2xA+3 would require four objects and their 
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Fig. 4. 1 laer panel for waveform 
plus noise application, 



associated connections (two constants, one add operation, 
and one multiply operation). Using HP VEE's formula box 
requires only the single expression object to solve this prob- 
lem. The point of a block diagram is to show an overview of 
how a complex system operates without regard to imple- 
mentation details. Had HP VEE been Implemented without a 
higher level of abstract ton. the resulting graphical program 
would have had so many boxes and lines that it would have 
resembled a maze rather than a block diagram. 

Development Proofs 

We followed a fairly informal development lifecycle for HP 
VEE. It was based on the spiral lifecycle, 1 which divides the 
development phase into a series of design/build/test cycles 
with a risk assessment before each. This worked very well 
for us for several reasons. Probably the most important fac- 
tor was that the team was small and highly motivated. This 
made rigorous checkpoints and detailed design documents 
unnecessary since all of the team members worked very 
closely together toward the same goals. Another important 
factor was the use of an object-oriented design approach 
coupled with very careful design practices. This allowed us 
to design classes according to their interactions with the 
rest of the system without spending a great deal of time im- 
plementing the internals of the classes. This is important in 
a spiral lifecycle because during each cycle, an entire class 
or set of classes may need to be reimpleincnlcd. Without an 
object-oriented approach, this would require an excessive 
amount of time rewriting other seemingly unrelated parts of 
the system. Another successful development decision was 
the early incorporation of a full-time software testing team 
to help us with the (est phases of the lifecycle. 



The Search for Primitives 

The initial functionality was specified by the team based on 
our experience as frustrated users of third-generation lan- 
guages (3GLs) such as Pascal, C, and BASIC. Certain tasks 
appeared over and over on the "I wish there were some 
other way to do this ..." list. Experience had already shown 
that because of limited flexibility, the usual subroutine library 
approach did not offer the type of productivity increase being 
sought. However, with our executable block diagram meta- 
phor, we felt that many of these tasks could be implemented 
as primitives in HP VEE while still providing the necessary 
flexibility. 

Foremost among these tasks were data management, engi- 
neering graphics, instrument control, and integration of mul- 
tiple applications. In each case we were convinced thai a 
higher level of abst raction could be developed t hat would In- 
flexible yet simple enough to require only minor configura- 
tion specification from the user in most situations. 

Data Management 

To lame the basic data management problem we developed 
the container architecture. Containers hold data, either ar- 
rays or scalars, of a wide variety of data types, and provide a 
rich set of mathematical intrinsics to operate on that data. 
Many operations such as type conversion and array process- 
ing, formerly left to the user, are incorporated into these 
object abstractions in a fashion that makes them relatively 
transparent. 

Anot her aspect of data management involves interfacing 
with the file system because so much effort must be ex- 
pended on il when using 3(JLs. We developed objects thai 
offer the powerful input/output capabilities of many SGLs, 
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Object-Oriented Programming in a Large System 



The biggest problem with a large software development effort is that there is |ust 
ton much complexity fur the tinman mind to manage The obvious solution is to 
add more people to the protect so that the members are not asked to manage 
more than their individual abilities permit Unfortunately, the law of diminishing 
returns applies, since each additional team member adds a very large communica- 
tion and training luad on the rest of the team In addition, there are increased 
opportunities for disagreement and conflict 

In some ways, development of large software systems is like one person trying to 
dig a canal using only a shovel Yes. it is possible, but probably not in that person's 
lifetime It more people are assigned to the task, n can be done more quickly, but 
only at an enormous cost However, if equipped with ihe right tools llwckhoes. 
earth movers, etc.). one person can accomplish so much that only a small numder 
of people are required to complete the proiect within a reasonable amount of time. 

This is exactly the idea behind object-oriented programming. By reducing the amount 
ol complexity that one soltware developer must manage, that one person can be 
responsible for a much larger portion of the system The result is that much higher 
productivity is attainable since smaller teams can be used, thereby avoiding the 
etfects ol the law of diminishing returns Features of object-oriented programming 
such as encapsulation and inheritance allnw one person to maintain a much larger 
portion of a large system than would be possible with a traditional approach 

Encapsulation is probably the strongest reason to use an object-oriented approach 
for a large system Object-oriented systems encapsulate functionality by combin- 
ing data and associated routines into one package (the class) and then disallowing 
access to the data except through one nf the routines. When this is done, code 
outside of the class is less likely to have dependencies on the structure or mean- 
ing of the data in the class since its only access to the data is through the access 
routines rather than directly to the data This allows a class to define the exter- 
nally visible interface separately from the internal implementation. Because of this 
basic structure, a class or even an entire hierarchy of classes can be completely 
rewritten without affecting other parts of the system as long as Ihe externally 
visible interface remains constant. 

Inheritance is another reason to use an ob|ect-onented approach m a large system 
Inheritance allows a new class to be written simply by specifying additions or 



changes to an existing class. This means that just a few lines of added code can 
provide a significant increase In functionality The other benefit of inheritance is 
that code reuse of internal routines is increased substantially For example, there 
is only one smgle-lme text editor in HP VEE. which is used for all single-line text 
entry fields However, since it is easy to add to the behavior of the editor class 
through inheritance, the numeric fields that allow constant expressions as numeric 
input are just a very small incremental effort over the original line editor They 
simply add to the "accept" mechanism ai the end of an editing session and pass 
the typed string to Ihe parser for evaluation as an expression before attempting to 
record Ihe numeric result 

However, features such as encapsulation and inheritance do not automatically 
result in a system thai is easier to maintain and build Very careful design practices 
must be followed and the team members must be motivated to do high-quality 
work Probably the most important design practice is careful partitioning of the 
system so that complexity In one area is not visible in an unrelated area 

An object-oriented approach coupled with careful design practices will often 
cause the software development effort to seem harder than with a more tradi- 
tional approach For example, in a traditional approach, if a variable in one module 
needs 10 be accessed in another module. H is easy to declare that reference directly 
to the compiler In an object-oriented approach, it is common for these variables to 
exist only as instance variables, which are not allocated until the owning class 
has been instantiated This means that the compiler cannot reference a value 
directly because it ooesn't exist until run time Therefore, a more complete solu- 
tion must be devised to find the required value This usually means that a mes- 
sage asking for the value must be sent to the object that knows the answer with- 
out ever directly accessing the variable This sounds harder, and it is. but in the 
long run the resulting code is much more maintainable and extendable 

William L Hunt 
Development Engineer 
VXI Systems Division 



Inil present litem In Ihe user by means of an interactive dia- 
log box to eliminate the need lo remember syntax. Each of 
these dialog boxes represents a single transaction with the 
file such as read, write, or rewind, and as many transactions 
as necessary can be put into a single Tile I/O object. 

Engineering Graphics 

For engineering graphics. Ihe task of finding a higher level 
of abstract ion was relatively easy. Unlike data management, 
engineering graphics is a fundamentally visual operation and 
as such it is clear that a single element in a block diagram 
can be used to encapsulate an entire graphical display. 
Therefore, we just developed the basic framework for each 
type digraph, and we present these to ihe user as graph 
displays that require only minor interactive configuration. In 
this area we had a rich set of examples to draw from because 
Of the wide variety of highly developed graphs available on 
HP instruments. In some cases, we were even able bo reuse 
the graphics display code from these instruments. 

Instrument Control 

Instrument control is a collection of several problems: 
knowing the commands required to execute specific opera- 
tions, keeping track of ihe stale of the instrument, and (like 
file L/C)) remembering the elaborate syntax required by 3GLs 
lo formal and parse the data sent over Ihe bus. We developed 



two abstractions to solve these problems: instrument drivel's 
and direct I/O. 

Instrument drivers have all of the command syntax for an 
instrument embedded behind an interactive, onscreen panel. 
This panel and the driver behind it are developed using a 
special driver language used by other IIP products in addi- 
tion to IIP VEE. With these panels the task of controlling Ihe 
instrument is reduced to interacting with the onscreen panel 
in much the same fashion as one interacts with the instru- 
ment front panel. This is especially useful for modem card- 
cage instruments that have no front panel at all. Currently 
HP provides drivers for more than 200 IIP instruments, as 
well as special applications that can be used to develop 
panels and drivers for other instruments. 

In some situations insirumeni drivers are not flexible 
enough or fast enough, or they are simply not available for 
the required instruments. For these situations, we developed 
direct I/( ). Direc t I/O uses transactions similar to the file I/O 
objects with added capabilities for supporting instrument 
interface features such as sending HP-IB commands. Direct 
I/O provides the most flexible way lo communicate with 
in s tr u me nts because il gives Ihe user control over all of ihe 
commands and data being sent across the bus. However, 
unlike instrument drivers, the user is also required to know 
the specific commands required to control the instrument 



76 October !9W Hewlett-Packard Joiima] 

©Copr. 1949-1998 Hewlett-Packard Co. 



To simplify Ihe process of reconfiguring an instrument for a 
different measurement, direct I/O also supports the upload- 
ing and downloading of learn strings from and to the instru- 
ment. A learn string is the binary image of the current state 
of an instrument. It can be used to simplify tin- process of 
setting up an instrument for a measurement A typical use of 
this feature is to configure an instrument for a spedBc mea- 
surement using its front panel and then simply upload that 
state into HP VEE. where it will be automatically down- 
loaded before making ihe measurements. Thus, the user is 
saved from having to learn all of the commands required to 
initially configure the instrument from a base or reset state 
before making the measurement. In most cases the user is 
already familiar with the instrument's front panel. 

Multiple Applications 

Multiple application integration turned out lo be one of the 
easiest tasks in HP VEE. since the inherent parallelism of 
multiprocess operations can be expressed directly in a 
block diagram. Each element of a block diagram must 
execute only after the elements that provide data for its in- 
puts. How ever, two elements that do not depend on each 
other can execute in any order or in parallel. This feature, 
along w ith the powerful formatting capabilities provided for 
interprocess communication, allows the integration and 
coordination of very disparate applications regardless of 
whether they exist as several processes on one system or as 
processes distributed ac ross multiple systems. The only 
object abstractions required to support these activities are 
those that act as communication pons to other processes. A 
pair of objects is available that supports communication 
with local processes (both child and peer) using format ting 
capabilities similar to those used by file and instrument I/O. 

Finally, we needed to develop objects that would encapsu- 
late several other objects to form some larger user-defined 
abstraction. This abstraction is available using Ihe user oh 
jcci. which can be used CO encapsulate an III' VEE block 
diagram as a unit It can have user-defined input and output 
pins and a user panel, and from the outside ii appears lo be 
JUS) like any other primitive object. 

Refining the Design 

While slill in Ihe early cycles of our spiral lifecycle, we 
snuglii a limited number of industry partners. This enabled 
us to incorporate design feedback from large! users attempt- 
ing real problems well before encountering design freezes. 
Although there were fears that such attempts would slow 
our development effort because of Ihe additional support 
lime required, we fell that Ihe payback in design refinement 
for both user interface elements and functional elements 
was substantial. 

One example of such a relinemeni in the user Interlace is 
the automatic line routing feature. Before line routing was 
added, our early users would often spend half of their time 
adjusting and readjusting the layouts of their programs. 
When asked why Ihey spenl so much time doing Ibis, they 
generally were not certain, but fell compelled lo do il any- 

We were very concerned about Ihe amount of lime 
being spent because it reduced the potential amount of 



produc tivity thai could Ik- gained by using HP VEE. Thus 
we added automatic line routing and a snap grid for easier 
object alignment so that users would spend less time trying 
to make their programs look perfect. 

An example of a refinement in the functional aspects of the 
product Is the comparator object Several early users en- 
countered the need to compare some acquired or synthe- 
sized waveform against an arbitrary limit or envelope. This 
task would not have been so difficult except thai the bound 
ary values (envelope) rarely contained the same number of 
points as the lest value. Before the comparator was devel- 
oped, this task required many different objects to perform 
the interpolation and comparison operations on the w ave- 
forms. The Comparator was developed to perform all of 
these operations and generate a simple pass or fail output. 
In addition, il optionally generates a list of the coordinates 
of failed points from ihe lest w aveform, since many users 
want to document or display such failures. 

Conclusion 

Early prototypes of HP VEE were used for a wide variety of 
technical problems from the control of manufacturing pro- 
cesses to Ihe testing of widely disltibuled telecommunica- 
tions networks. Many began exploring il to orcheslrale Ihe 
interaction of other applications, especially where network 
interconnections were involved. 

( iirrent experience suggests that Ihe block diagram form of 
problem expression and its companion solution by means of 
dataflow models has w ide applicability to problems in many 
domains: science, engineering, manufaetiuing, telecommu- 
nications, business, education, and many others. Many 
problems that are difficult to translate to Ihe inline text Of 
third-general ion languages such as Pascal Ot G are easily 
expressed its block diagrams. Potential users who are ex- 
perts in I heir own problem domain, but who have avoided 
computers in the past, may now be able to extract real value 
from computers simply because ihey can express their prob- 
lems in the more natural language of Ihe block diagram. In 
addition, large-scale problems that require Ihe expert user lo 
Orchestrate many different bill related applications involv- 
ing multiple processes and/or systems can now be handled 
almost as easily as Ihe simpler problems involving a few 
variables in a single process 

Acknowledgments 

We would like to thank design team members Sue Wolber, 
Randy Bailey. Ken Colasuonno, and Bill llein/.man, who 
were responsible for many key features in IIP VEE and who 
patiently reviewed the HP Journal submissions. We would 
also like to I hank Jerry Schneider and John Frieman who 
pioneered the testing iTforl and prov ided many key insights 
on product features and usability. More than any other we 
would like to thank David Palermo without whose far-sighted 
backing through the years we could not have produced this 
pit tduct. 

Reference 

i it W Boehnii "A Spiral Model of Software Development ami 
Enhancemtnt,* f BEE Computer, May 1988. 



© Copr. 1949-1998 Hewlett-Packard Co. 



Ociobci 1092 Hewlett-Packard Journal 77 



Developing an Advanced User 
Interface for HP VEE 



Simplicity and flexibility were the primary attributes that guided the user 
interface development. Test programs generated with HP VEE can have 
the same advanced user interface as HP VEE itself. 

by William L. Hunt 



IIP VEE. Hewlett -Packard's visual engineering environment; 
was developed as a programming lool for nonprogrammers. 
in the past, computer users were required i<> move into the 

computer's domain. Our goal lor III' VEE was lo bring Ihe 
Computer Into the user's domain. This meaiil developing a 
sysiem Ihal operates in Ihe way that our target users expect. 

To accomplish this goal, ease of use was of critical imper- 
ial ire. However, because most target users of IIP VEE are 
highly educated technical professionals, simple-minded ap- 
proaches to user interface design were not appropriate. For 
this audience, the system must be powerful and llexible. but 
must not become an obstacle because of overprolection. 

With these constraints in mind, we decided that the primary 
attributes of IIP VEE should be simplicity and flexibility. 
Leamabilily was also considered to be important, but we 
fell that no one would bother to team the system unless it 
were a truly useful and powerful tool. Therefore, we fell that 
we could compromise some leamabilily in situations where 
a great deal of the power of the system would be lost if 
learnability were our primary goal. < )ur overall approach, 
therefore, was to design a system I hat is as natural to learn 
and use as possible and powerful enough that our customers 
would be excited about learning how to use it. 

Development Guidelines 

In general, simplicity is very' important in a user interface 
because it frees the user from having lo worry about unnec- 
essaiy details or rules. The Underlying goal of a good user 
interface is lo increase the communication bandwidth be- 
tween the computer and Ihe user. Howev er, this does not 
mean that there should be a myriad or displays and indica- 
tors. In fact, unite the opposite is true. The more things there 
are for the user In comprehend, the greater Ihe chance Ihal 
Something will be missed. The goal, therefore, should be lo 
reduce the amount of data that the user must be aware of 
and present the essential dala in Ihe simplest and mosl com- 
pact way possible. Similarly, any piece of data presented to 
the user should always be presented in a consistent waj be- 
cause this is known lo increase comprehension dramatically. 

An example of a simple way lo present information to the 
user is the 3D look used in the OSF/Motif graphical user 
interface and more recently in other systems such as Micro 
soli : Windows. When used properly. Ihe :3I) borders can be 
used lo communicate information about the stale of individ- 
ual fields without consuming any additional display space. 



Fig. 1 shows how HP VEE uses the 3D look to identify how 
fields will respond to user input . Fields ihal are editable are 
displayed as recessed or concave. Buttons and oilier fields 
that respond lo mouse clicks are shown as convex. Fields 
that are only used as displays and do not respond to input 
are shown as Hat. These states are very simple to compre- 
hend because the throe states are unique in Ihe way that 
they look and operate. Without realizing it. users will natu- 
rally learn how to identify which fields are editable, which 
fields can be activated, and which fields will not respond to 
Input This 3D display technique allows these slates to be 
displayed without any additional display area. 

Fundamentally. HP VEE was designed around the concept 
of direct manipulation This means that wherever possible, a 
setting can be changed by operating directly on Ihe display 
of that selling. This results in a significant simplification for 
the user since special operations or commands are not gen- 
erally required lo make changes 10 sellings. For example, 
the scale of a strip char! Is shown near the edges of the 
graph display (Fig. 2). If the user wants to change Ihe graph 
scaling, the limit fields themselves can be edited. It is not 
necessary to make a menu choice lo bring up a pop-up dia- 
log box for editing the scale. In many other systems, making 
any change requires a menu pick. This effectively reduces a 
sysiem to a command-line Interface that happens lo use a 
mouse and menus instead of Ihe keyboard Such a sysiem is 
no easier lo use than the command line interface systems of 
Ihe past. 

Flexibility is more important lor an easy-to-use system than 
for more traditional systems because there is a perception 
that power and ease of use cannot be combined in Ihe same 
system. In Ihe past, powerful systems have generally been 
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Fig. 1. A viewcniilaining a noneditahle field, two buttons; WKl somp 
editable fields. 
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Fig. 2. Direct manipulation is useful for settings such as graph 
limits 

hard to use and easy-to-use systems have generally not 
been very flexible or powerful. To overcome this perception, 
therefore, an easy-to-use system must be very powerful so 
that potential customers' fears can be overcome. When de- 
signing HP VEE, we were very careful to avoid limiting flexi- 
bility wherever possible. It often seemed as if we were faced 
with a choice between ease of use and flexibility. However, 
with careful consideration of the alternatives, we usually 
found that the more flexible approach could be implemented 
with an easy-to-use interface. 

Flexible and powerful systems are naturally very complex 
because there are so many features and capabilities to re- 
member. In these systems, it is extremely important that each 
area of the system operate in a way that is consistent with 
the rest of the system because even the most advanced users 
are rarely familiar with all aspects of the system. I'sers must 
be able to rely on their experience with other parts of the 
system In help guide i hem through the unfamiliar areas. 
For this reason, consistency was an important guideline 
throughout the development of HP VEE. 

High performance for interactive Operations is critical be- 
cause users will become frustrated using a product that is 
loo slow. Very few users will be happy if they must wait an 
inordinate amount of time before a particular operation is 
Complete. The allowable time for the system to complete a 
task depends on the nature of the task and what the user is 
likely to be doing at the time. For example, a key press 
should be echoed back to the user wilhin about 100 ms or 
so. If il lakes longer, the user may press the key again think- 
ing that the system didn't gel the first one. A pop-up dialog 
l>ox or menu sliould appear witliin ahOHt fiflfl ms. Other 
tasks such as loading a file can take many seconds before 
the user will become annoyed because of sluggish perfor- 
mance. We created a list of about ten different interactive 
operations for which we fell that performance was an im- 
portant goal. On all supported platforms, many of the Opera- 
tions in this list such as the pop-up menus and dialog boxes 
are completed wilhin the required time. I 'nfortunately, there 
are still a few operations that are completed wilhin the spe- 
cified time limits only on the very fast HP 0000 Series 700 
workstations. On the other hand, we have received very few 
complaints about interactive performance, so our time limits 
may have been overly Stringent 

In some situations, such as saving a file to the disk, perfor- 
mance simply cannot be guaranteed. In these cases, continu- 
ous feedback indicating progress being made is important. 



Otherwise, it isn't easy to tell whether something is happen- 
ing or not. In HP VEE, all user-invoked operations that could 
take more than about 200 ms will result in a change to the 
mouse cursor. Some of these cursors represent specific ac- 
tivities such as reading from or writing to the disk. For other 
situations, a general hourglass cursor is used. Any action 
that is expected to take longer than one or two seconds is 
also accompanied by a pop-up message box that indicates 
that the operation is in progress. 

Reducing the total number of mouse dicks, menu choices, 
and various other adjustments required of the user was a 
major challenge. Each adjustment required of the user, no 
matter how easy, will reduce the user's overall effectiveness. 
For this reason. HP VEE is designed to do as much as pos- 
sible with default settings while allowing adjustments if 
more control is desired. Other systems often require that the 
user fill out a form each time a new object is selected from 
the menu. In most cases. IIP VEE will insert default values 
for all settings and then allow the user to change them later 
if it becomes necessary'. 

System messages for errors and other reasons are an espe- 
cially important source of difficulty or frustration for users. 
Most software developers seem to take the attitude of a hos- 
tile enemy when presenting the user with an error message. 
Howev er, errors are seldom true user mistakes, but instead 
are usually triggered by failings in the system either because 
it misled the user or because it did not adequately protect 
the user from making the mistake in the first place. In many 
cases in HP VEE, we were able to avoid generating errors 
simply by restricting available choices to those that would 
not result in an error. For example, if a certain combination 
of selections will cause an error, we show them as mutually 
exclusive choices. In cases where such restrictions could 
not be used to avoid the potential for an error, we worked to 
simplify the interface so that users would be less likely to 
make mistakes in the first place. In cases where errors were 
unavoidable, we kept the attitude that error messages should 
help the user complete a task. We tried to remember that 
the user generally has a valid reason for performing jthe 
operation that resulted in an error. 

Two kinds of messages that are common in many systems 
are not present in IIP VEE. The first is the message "Please 
wait," It is irritating to users because they don't want to wail 
and they are being instructed to do so. The message is also 
unnecessary since more descriptive messages can be useel 
instead. Messages such as "Reading from file progtam2" are 
much more Informative and are not nearly so annoying. The 
other common message is a confirmation box that asks "Are 
you sure?" This is also very annoying because the user sel- 
dom initiates any operation without being pretty sure about 
wanting to perform that operation. There are really two rea- 
sons for asking "Are you sure?" One is to caution the user 
about data loss and the other is to protect against accidental 
requests. 

In IIP VEE, we solve the first situation by asking a question 
such as "Save changes before clearing workspace?" This has 
the same result as "Are you sure?", but does not sound as if 
(he user's choice (or sanity) is being questioned. 

In the second situation, accidental requests ate better solved 
by making the input mechanisms easier to operate without 
error or by making corrections easy to perform. For example, 



© Copr. 1949-1998 Hewlett-Packard Co. 



( Irtolx-r \W2 Hewlett-Packard Journal 79 



Instead of asking "Arc you sure?" to find out if the user really 

wants to delete an object, IIP vee puis the deleted object 

ink) the cut buffer so thai if the user decides lhat a mistake 
was made, the pasle operation can tie used to restore the 
deleted object. 

Attention to detail is very important to a user. Most systems 
available today lack the small details thai make a system 
more convenient and easier lo use. In HP VEE. we have at- 
tempted to pay attention lo as many of these small details as 
possible. For example, when connecting a line to a box, an 
outline is displayed around the pin that would be connected 
if the line were released at lhat point. Another example of a 
very small detail is that IIP VEE allows objects to be resized 
as they are being placed on the workspace for the first lime. 
These seemingly minor details help reduce the amount of 
frustration that users often feel. 

Program Visualization Features 

In a traditional programming environment, the programmer 
must spend a large fraction of the development time think- 
ing about details of the programming process including the 
language syntax, debuggers, and so on. Since IIP VEE allows 
the user lo think almost exclusively in terras of the problem 
domain, most of the development time and effort is spent on 
solving the problem instead of the programming details. 
This is the primary source of the productivity gains that 
many users of IIP VEE have experienced. However, even 
though IIP VEE allows programs to be expressed directly in 
terms of the problem, not all user-written programs will run 
Correctly the firsl time. Although the so-called accidental 
complexities 1 of program development such as language 
syntax and semantics have been reduced or even eliminated, 
the fundamental complexities of the problem itself still re- 
main. Therefore, once an IIP VEE program is developed, it is 
likely lhat some aspect of it will not quite work as expected. 
For this reason, we developed several tools that can be used 
lo visualize the execution of a program to help identify the 
source of any problems. 

Show Execution Flow animates the execution of the program by 
outlining each object as it begins to execute and then eras- 
ing lhat outline when execution is complete. Besides helping 
lo visualize how the program executes, this is useful when 
trying to understand performance issues, since an object in 
the program that consumes a lot of time w ill be highlighted 
for more lime than Other objects. IIP VEE also has a timer 
object, w hich allows a more objective way to measure 
performance. 

Show Data Flow animates the movement of data as it travels 
between objects in the program by displaying an icon mov- 
ing rapidly along each line as data flows across it. This helps 
the user visualize the relationships between the data and the 
execution of the objects of a dataflow p rogr am . Both Show 
Execution Flow and Show Data Flow slow the execution of HP 
VEE programs so much that they are designed to be turned 
on and off separately. 



All data in IIP VICE has additional information such as size 
and shape associated with it. This information is maintained 
so that one operat ion can work with a variety of different 
data types and shapes. For example, math functions such as 
sin( ) can operate on either an individual number or an array 
of numbers with any number of elements. This is possible 
because the size and number of dimensions are packaged 
witJi the data. Other information such as the name of the 
data and mappings (the implied domain of Hie data) can also 
be associated with the data. The line probe feature allows 
the user to examine the data and this associated information 
at any lime. 

The execution of a program can be halted when execution 
reaches a particular object simply by setting that object's 
breakpoint flag. Breakpoints can be sel on any number of 
objects at any time. When execution reaches an object with 
its breakpoint Hag sel. the program will pause and an arrow 
pointing to that object will appeal*. At that point the slep 
billion can be used lo single-step the program one- object at 
a time or the line probe can be used to examine data. 

If an error occurs during execution of the program and no 
error recovery mechanism has been attached, a message 
will be displayed and an outline will highlight the source of 
(he error visually. This allows the user to locate the source 

of the error more quickly. 

Fser Interface for HP VEE Programs 

Since a user of IIP VEE should be able lo generate programs 
w ith the same advanced user interface as IIP VEE itself, 
several important capabilities have been incorporated into 
IIP VEE lo make I he task of building impressive-looking 

programs simple. 

For example, daia can be entered using a variety of data 
entry objects. The simplest of these is a text field thai accepts 
a single line of textual data. Numeric fields of various types 
such as integer, real, complex, or polar complex accept the 
appropriate numeric dala. In addition, these numeric fields 
can accept constant expressions such as "SQRT(45)" or 
system-defined constants such as "PI." When typed, these 
constant expressions are immediately evaluated and the 
result is converted to Ihe expected type by the input Held. 
Since all editable fields in 111' VEE share the same editing 
code internally, any numeric Held in the system lhat requires 
a numeric entry can also accept a conslanl expression. 

There are other more advanced mechanisms for entering 
data or specifying selections to an IIP VEE program. Integer 
or real numeric input can be generaied within a predefined 
range by using the mouse to drag the handle of a slider ob- 
ject. Selections from a list of acceptable values can be made 
using an enumerated list box. which can he displayed as 
radio buttons, as a single button that cycles through the list 
of values, or as a button that accesses a pop-up list box of 
choices. An IIP VEE program can be designed to pause until 
tin- user is ready lo continue by using the Confirm button. 
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Data can be displayed in a variety of ways. In addition to 
textual displays, real or integer numbers can be displayed 
on a meter object, which can show visually where a number 
falls within a range. Graphical displays such as XY graphs 
and polar plots show two-dimensional plots of data and 
ran be interactively scrolled or zoomed. Stripcharts graph 
a continuous scrolling history of the input data 

All of these input and output types would have limited value 
if they could only be displayed when the rest of the IIP VEE 
program with all of its lines and boxes is also visible. For 
this reason. HP VEE is designed with a feature c alled user 
panels, which allows an advanced user interface to be at- 
tached to a user-written HI* VEE program. The user panel is 
built using an approach similar to many of the available user 
interface builders. Elements to be placed on the user panel 
are selected from the HP VEE program and added to the 
panel. The user can then move and resize these elements as 
appropriate for the design of the panel, t Mhcr layout optimis 
such as whether a title bar appears can also be adjusted. 
Since the elements on the user panel are selected from the 
user's program, no external code is required and the finished 
program is easier to build than with most user interface 
builder tools. 

Another important aspect of an advanced human interface is 
the ability to hide data until the user has asked to examine 
it. IIP VEE is designed with a feature called Show On Execute 
which allows IIP VEE programs to use pop-up windows to 
hide data until a user request is received. This works by 
associating a user panel with a user object (similar to a sub- 
routine in traditional programming languages) and enabling 
the Show On Execute feature; When the user object begins 
executing, the associated user panel is automatically dis- 
played. When execution of the object is complete, the user 
panel is erased. Messages such as "Writing lest results to file" 
can be displayed using this mechanism simply by putting the 
appropriate message on the associated user panel. If it is 
desirable to pause the program until the user lias finished 
examining the displayed panel, a confirm object can be used. 

Programs developed in IIP VEE are highly malleable: they 
can be changed and adjusted as much as desired. I lowever. 
in many situations it is desirable to protect the program 
from being changed. The secure feature in IIP VEE accom- 
plishes this by displaying only the user panel and making it 
impossible to alter the program or even look at it after the 
program has been secured. 
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Fig. 3. Simplified class hierarchy of HI' VEE 

I "sing all of these features allows users to generate complete 
application programs with professional appearances without 
having 10 work outside of the simple dataflow environment. 

Internal Architecture 

Pig. ;) shows a simplified class hierarchy for IIP VEE show- 
ing some of the key classes in the system and how they re- 
late to each other in I he inheritance hierarchy. The Object 
class is at the root of this hierarchy and implements the fun- 
damental protocol for all objects in the system. This includes 
creating, freeing, and copying objects. The key subclasses of 
Object include View, which maintains a rectangle on the dis- 
play. Container, which holds a unit of data, and Device, which 
represents the inner workings of an element in an HP VEE 
block diagram. 

The fundamental visible element in IIP VEE is implemented 
with the- class called View. It maintains a single rectangular 
region on the display and can be transparent or a composite 
of other views. The View3d class adds a solid background 
color and a -il > border to View. 

Views are organized into a hierarchy tree based on the dis- 
play slacking order. The rool of this tree is called DispDnver. 
It is always mapped to overlay the system window allocated 
to HP VEE. It performs all low-level screen display opera 
tions such as drawing lines and filling regions. Il also han- 
dles the window system interface functions such as repaint 
requests and dispatching of input events. Fig. -1 shows a 
composite of views in a view hierarc hy with some of the 
views labeled with the name of their associated class, Fig. 6 
shows I he complete hierarchy tree Of the views in Fig. 4. 
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Fig. 5. Display hierarchy tree. 

Suhviews are views thai are attached lo another view called 
the snperview in the display hierarchy Iree. Suhviews are 
clipped at the edges of Iheir superview. In this way, each 
level of I he view hierarchy Iree limits the visual boundaries 
Of all Views below it. This view hierarchy indirectly de- 
scribes the view stacking order, which ullinialely controls 
which views appear to be on top and which ones are hidden. 

Each view maintains a description ofthe region on which it 
is allowed lo display itself. This clip region is calculated by 
taking its own bounds, subtracting any region thai falls out- 
side the hounds of any view in ils superview hierarchy, and 
Ihen subtracting any views ilia! partially or completely 
cover it or any view in its superview hierarchy. 

Repainting 

When repainting an area I hat it is maintaining, a view may 
either use the clip region to limit the areas it actually changes 
on the display, or it may paint any area that it owns and then 
paint every view that appears closer to the user in the view 
stack. The full view stack repaint method has nothing lo 
calculate or check before it begins painting itself completely 
and ihen painting anything thai might be on top of it, If noth- 
ing is on top of it, then the complete slack repaint is very 
efficient because it is so simple. However, if there are many 
other views covering the view to be repainled. the full slack 
repaint will be very slow because of all of the unnecessary 
repainting that must be done. The clip region repaint method 
is much more efficient in this situation since only those 
areas that are directly visible to the user will be repainted. 
This means that no unnecessary repainting must be done. 

Unfortunately, the clip region is at best an approximation 
since views are allowed to display images of arbitrary com- 
plexity (such as text ) and be transparent in other areas. This 
gives the user the illusion thai views can have any shape 
without incurring ihe performance penalties associated with 
nonrcctangular views. It would be very costly to calculate 
these regions accurately, so only the approximation based 
on the rectangular view bounds Ls actually calculated. This 
means that repaints using Ihe clip region method will not 
correctly Update regions behind transparent areas of other 
views. Therefore, the clip region repaint method is used in 
only a few special cases. 



Input events such as mouse clicks are dispatched to individ- 
ual views in the system using a two-phase search mecha- 
nism. In the first phase, working from back to front, each 
view in I lie view stack where the event occurred asks the 
views in front of it to process the event. When there are no 
more views in front of the current view, the second phase 
begins with an attempt to consume the event. Working from 
front to back, each view in the view stack (as determined 
during the first phase) is given an opportunity to consume or 
ignore the event. If the view takes no special action, the 
event is passed to the next view down in the view stack. If 
the the view intends to consume the event, it does so by 
performing an action associated with the event such as indi- 
cating that a button has been pressed and then marking the 
event as consumed. This process continues until the event is 
consumed, or until the DispDnver class is given the event (this 
class consumes all events). 

Other Classes 

The visible pan of each object in an IIP VEE program is 
maintained by the DevCarrier class. DevCarner's job is lo main- 
tain the visual appearance of all objects in the system by 
showing the terminal pins, maintaining ihe various high- 
lights and outlines required by HI' VEE. and allowing vari- 
ous editing operations on the user's program such as con- 
necting lines anil adjusting the sizes or positions of objects. 
DevCarrier does not display any object -specific information. 
That information is displayed by object -specific view 
classes, which are attached to DevCarrier as suhviews. 

I'ser objects are specialized objects that are built using a 
subclass of DevCarrier called SubProg. SubProg maintains a 
visual subprogram which acts just like a normal Objed when 
viewed from Ihe outside, but contains an internal dataflow 
network of its own thai is just like Ihe main program. All of 
the dataflow networks in IIP VEE are maintained by a class 
called ConView (context view). It is Ihe gray background area 
behind the lines and boxes in a dataflow network. 

The lop-level workspace environment class — IPEditor (iconic 
program editor) — is just a special case of SubProg and is 
therefore built as a subclass of SubProg. It is attached as the 
only suhview of DispDriver and maintains Ihe lop-level editing 
environment. It is the same as SubProg, except that it must 
maintain Ihe menu bar, run/stop bullous, and other features 
specific to the lop level. 

The context view class ( ConView ) maintains a list of all ob- 
jects in the context and the lines connecting them. When Ihe 
context view is asked lo repaint itself, it first paints its back- 
ground color (gray, by default ). and Ihen paints all lines in 
Ihe line list. Then each IIP VEE object in Ihe context is 
painted according to the slacking order. If an HI' VEE object 
falls partially or completely outside Ihe context view's 
bounds, Ihen according to the clipping rules, thai view will 
be only partially painted or not painted at all. 

The clipping and repaint algorilhnis allow an HP VEE pro- 
gram lo be visually much larger than the screen space al- 
lotted to it. By adding navigation controls such as the back- 
ground scroll capability, a very large dataflow network can 
be supported even on a comparatively small screen. 
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Model-\Iew Architecture 

HP VEE is organized around a model-view architecture. This 
is similar to the model-view-controller architecture used in 
other object-oriented systems except that we chose to 
merge the functionality of the controller into the stew. The 
fundamental assumption in the model-view architecture is 
that the internal data and program elements (the models) 
can operate without any knowledge of or dependence on 
their visual representations (the views). By separating the 
system at this natural boundary, both the views and the 
models can be written more simply without any unneces- 
sary dependencies. One feature of this architecture is that 
one model can be attached to any of several different views 
without any special support in the model. For example, a 
model that contains a real number can be attached to a text 
field or to a meter. Since the properties of the number do 
not change based on how it is displayed, no changes are 
required of the class that holds the number. However, since 
there are few similarities between a meter view and a text 
view, they need not be built with one view class. 

User panels are one area that really benefit from the split 
between models and views. When the user selects an HP 
VEE object such as a slider and asks that it be added to the 
user panel, several things happen internally to make that 
happen. First, if a user panel has not been created for this 
program or user object, one is created. The user panel class 
is similar in concept to the context view class, but without 
support for interconnections required for dataflow net- 
works. Next, an instance of the PanelCarrier class is created to 
hold a copy of the object-specific part of the slider view. 
This copy is created from the original and attached to the 
new panel carrier and to the original slider model (which is 
not copied). The panel carrier is then attached to the user 
panel view. 

One of the most significant architectural impacts of the im- 
plementation of user panels is the fact that there can be 
many independent views attached to the same underlying 
model at the same time. Because of this architecture, it is 
easy for panels from user objects to be added as a unit lo 
highex-level panels. This allows the creation of complex 
panels consisting of grouped controls and displays. 



The DispDnver class is designed to be the only place w here 
calls to the underlying window system (such as the X Win- 
dow- System) occur. This allows the display driver to be re- 
placed if appropriate when porting to a new platform. Dur- 
ing development, for example, we used a driver written to 
talk directly to the display card of an HP 9000 Series 300 
computer because it ran so much faster than the window 
systems. Now that very high-performance workstations are 
available, this is no longer necessary. 

Printing is handled simply by replacing DispDnver with the 
printer driver class, which knows how to perform graphics 
operations on a printer. The information intended for the 
printer is just "displayed" on the printer and no special 
printer support must be developed aside from the printer 
driver itself. This also allows the print output to match the 
screen display very nicely, 
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HP VEE: A Dataflow Architecture 



HP VEE is an object-oriented implementation. Its architecture strictly 
separates views from the underlying models. There are two types of 
models: data models and device models. Special devices allow users to 
construct composite devices. 

by Douglas C. Beethe 



The HP VEE dataflow programming environment was devel- 
oped with the specific objective of providing ;ui interface that 
would allow users to express a problem in block diagram 
form on the screen and then execute it directly. Dataflow 
programming was chosen because of its direct correlation 
to the block diagram models we wished to emulate. 

Previous efforts in industry and academia related to data- 
flow programming had yielded some interesting results, but 
general applicability had not yet been established. Thus our 
early research efforts were directed primarily at the question 
of whether we could solve some of the problems thai had 
plagued earlier attempts and prove general applicability. 

The design and construction of IIP VEE used object-oriented 
technology from the beginning. We had enough experience 
with procedural coding technology to realize that a project 
like HP VEE would be too complex to achieve with proce- 
dural technology. The architecture that evolved from this 
development is the subject of this article. The design of vari- 
ous elements of the underlying IIP VEE architecture will be 
discussed as will the manner in which they work together to 
produce the executable block diagram as a dataflow model. 

The Model-View Paradigm 

One of the characteristics of the 1 IP VEE architecture that is 
common to most object-oriented implementations is the 
strict separation between models and views. Most users are 
familiar with the world of views, and indeed often make no 
distinction between the view of an object and its underlying 
model. 

From a functional point of view the model is the essence of 
an object, incorporating both the data (state variables) that 
gives the object its uniqueness, and the algorithms that oper- 
ate on that data. In IIP VEE. by definition, the model oper- 
ates independently of the view, and does not even know of 
the existence of any graphical renderings of itself, except as 
anonymous dependents that are alerted when the state of 
the model changes (see Fig. 1 ). 

There are many examples of applications that have views 
possessing no underlying fund ional models. Consider the 
various draw and paint programs, which allow the user to 
create very sophisticated views that, once created, are inca- 
pable of performing any function other than displaying 
themselves. Likewise, there are numerous examples of ap- 
plications that support very' sophisticated functional models 
but lack any ability to display a view of those models, be it 
for passive display of state or for active control. 



Most of the scientific visualization software appearing today 
is used to create \iews of the data output of functional mod- 
els that have little or no display capability. Most of the \iews 
that arc seen by the HP VEE user are actually graphical ren- 
derings of the states of underlying models. In the interactive 
mode, access to the models is by means of these views, 
which communicate with their respective models to change 
their state, initiate execution, and so forth. For example, the 
view of the ForCount iterator has a field in which the user can 
enter the number of times the iterator should fire at run 
time. Upon entry, this value is sent to the underlying device 
model, where it is kept as a state variable. When this stale 
variable is changed, the model sends out a signal to anyone 
registered as a dependent (e.g., the view) thai its state has 
changed, and the view then queries the model to determine 
the appropriate stale information and display it accordingly 
(see Fig. 2). 

This strict separation between model and view might seem 
excessive at first, but il results in a partitioning that makes 
the task of generating the two different kinds of code (very 
different kinds of code!) much easier from the standpoint of 
initial development, portability, and long-term code mainte- 
nance. It also eases the job of dealing with noninteractivc 
operations in which IIP VEE is running without any views at 
all, eil her by itself or as the slave of anol her application. 
And finally, this separation eases the task of developing ap- 
plications that must operate in a distributed environment 
where I he models live in one process while I he views are 
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Fig. 1. Two differeni views of the same underlying model. 
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Fig. 2. Interaction of a view and the underlying model at edit lime. 

displayed by another process, possibly on an entirely differ- 
ent system. This last aspect is becoming more and more 
important in an application world thai is taking increasing 
adv antage of networked systems. 

HP VEE itself is composed of two kinds of models. The first 
is the device model, which acts like a black box having in- 
puts, otilputs. and some operational characteristic thai 
transforms the data at the inputs to the result at the outputs. 
The second is the data model (container), which handles the 
transport of information along the data lines, which inter- 
connect devices. The dala model also provides mathemati- 
caJ functions, which can be invoked to operate on the dala. 
and formatting and deformatting functions, which change 
the representation of the data when required for display or 
for communication with some other application that requires 
the dala in a different form. Both types of models will be 
discussed in some detail. 

Data Models 

The fundamental abstraction for information in HP VEE is 
the container object (Fig. 3). Containers can hold data for 
any of the supported data types: text, enumerated, Integer, 
real, complex, polar complex, coordinate, waveform, spec- 
trum, and record. Both scalars (zero dimensions) and arrays 
from one to ten dimensions are supported. In addition, the 
dimensions of array containers can be mapped in either lin- 
ear or logarithmic fashion from a minimum value at the first 
cell of a dimension to a maximum v alue at the last cell of 
that dimension. This allows an array of values to have some 
physical or logical relationship associated with the dala For 
example, a one-dimensional array of eleven measurements 
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Fi«. S. Container model attributes. 



Supported Data Types 
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can be mapped from 0 to 32 cm to indicate the physical rela- 
tionship of the values in each position in the array to some 
real-world phenomenon. The first value would be at 0 cm, 
the next at 3.2 cm. the next at (14 cm. and so on. 

One of the properties of containers that is used extensively 
in HP VEE is the knowledge of how to transform to another 
type on demand. The automatic form of this transform is 
allowed only for transforms that incur no loss of informa- 
tion. This has the effect of allowing most promotions, bul 
disallows any automatic demotions. For example, integer 
can be promoted to real, and real to complex or polar com- 
plex, but complex cannot be demoted automatically to real. 
To do so would likely cause the loss of information that 
would not reappear in the promotion of that real value back 
lo complex. An interesting special case of this is the revers- 
ible transformation between waveform and spectrum (time 
and frequency domains). While these data types seem to 
have the same irreversible relationship to each other as the 
real and complex types just discussed, it is a well-known 
fact that a reversible transformation exists between these 
two special types by means of the Fourier transform. For 
example, a 256-point waveform is transformed lo a 129-point 
spectrum (ignoring the symmetrical values with negative 
frequency), and the same spectrum regenerates the original 
256-point waveform by means of I he inverse Fourier 
transformation (Fig. 4). 

Another powerful property of containers is their inherent 
knowledge of data structure as il applies lo mathematical 
operations. At first glance, operations such as addition and 
subtraction seem relatively simple, but only from the stand- 
point of two scalar operands. For other structural combina- 
tions (scalar + array, array + scalar, or array + array) the task 
requires some form of iteration in typical third-general ion 
languages (3GLs) like (' that has always been the responsi- 
bility of the user-programmer. Containers encapsulate these 
well-understood roles so that the user deals wilh, say. A mid 
B simply as variables independent of si ruct lire. When any of 
the nonlrivial combinations is encountered, the containers 
decide among themselves if there is an appropriate struc- 
tural match (scalar with any array, or array with confoi tnal 
array) and execute the appropriate operations to generate 
the result. 

Other more complicated operations with more robust con- 
st taints (e.g., matrix multiplication) are handled just as easily 
Since the appropriate structural rules are well-understood 
and easily encapsulated in the containers. These properties 
aid the user in two ways. First, the user can express power- 
ful mathematical relationships either in fields that accept 
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Fig. 5. Attributes of a simple device model. 

constant expressions or in any of several delaycd-evaluation 
fields (e.g.. Formula, If/Then, ...) without having to deal With the 
cumbersome iteration syntax of 3GL programming. This by 
itself has the pleasant side effect of eliminating much if not 
most of die iteration in many applications, compared to their 
3GL equivalents. Second, the interconnection of the various 
objects that make up a model in HP VEE is much simpler 
when any of the inputs is constrained to a specific data type. 
Since the containers know how to respond to most requests 
for type change, the user is freed from the cumbersome task 
of explicitly changing (casting) the original type to the re- 
quired type. For example, the inputs to a spectral display 
that requires a spectrum input will not disallow connection 
to a waveform (time-series data) because the output supply- 
ing the waveform will transform it to a spectrum on demand 
at run time. This same capability is used during the evalua- 
tion of any mathematical expression, thus allowing the user 
to intermix types of operands without explicit type casting. 

Device Models 

Fig. 5 shows the attributes of a simple device model. Each 
device can have its own inputs and outputs. Many have user- 
controllable parameters that are accessed as constants 
through the panel view of the device or as optionally added 
inputs. In general, the device will execute only when each of 
the data inputs has been given new data (including nil data). 
Thus the data inputs to any given device define a system of 
constraints that control when that device can execute. This 
turns out to be quite natural for most users since the data 
relationships that are depicted by the data lines that inter- 
connect devices generally map directly from the block dia- 
gram of the system in question, and often are the only form 
of constraint required for the successful execution of a 
model. 

There are numerous cases, however, where an execution 
sequence must be specified when no such data dependen- 
cies exist. Such cases typically fall into two categories: 
those where there is some external side effect to consider 
(communications with the real world outside my process) 
and those that deal explicitly with real time. To deal with 
this situation we developed the sequence input and output 
for each device (on the top and bottom of the device, re- 
spectively), as shown in Fig. 6. The sequence output be- 
haves like any other data output by firing after successful 
execution of the device except that the signal that is propa- 
gated to the next device is a always a nil signal. Likewise, 
the sequence input behaves like any other data input with 
one exception. When connected it must be updated (any data 
will do, even nil) along with any other data inputs before the 




Fig. 6. While B and C both need the data from A. the sequence 
i 1 1[ ii i« -i t iim between B and C will cause C to execute after B. 

device will be allowed to execute, but unlike other data in- 
puts, connection is not required. Thus any time it is required 
that A must execute before B where no other data dependen- 
cies exist between the two devices, it is sufficient to connect 
the sequence output of A to the sequence input of B. 

For users who have already been introduced to program- 
ming in third-generation languages such as Pascal, C, or 
BASIC this can require a paradigm shift. Experience with 
such users has shown that they are often preoccupied with 
sequencing (since 3GLs almost universally use control-flow 
paradigms) and have a difficult time at first believing that 
the data constraints represented by the lines that intercon- 
nect the devices are sufficient to define a robust sequence of 
execution. It is only after using the system for a time that 
they are weaned away from this need to sequence each and 
every device explicitly and begin to feel comfortable with 
the dataflow paradigm. 

Contexts 

Several types of devices are supplied as primitives with IIP 
VEE, including those used for flow control, data entry and 
display, general data management, mathematical expressions, 
device, file, and interprocess I/O, virtual signal sources, and 
others. There is also a mechanism that allows users to con- 
struct special devices with their own panels and a specific 
functional Capability This device is known as a UserObject 
and is essentially a graphical subprogram. 

UserObiects (Fig. 7) encapsulate networks of other devices 
( including other UserObjects) and have their own input/output 
pins and custom panel displays. Viewed as a single collec- 
tive object with its own panel, each UserObject operates un- 
der the same rules as any primitive device: all data inputs 
must be updated before the UserObiect will execute its inter- 
nal subnet. Each UserObiect will contain one or more threads, 
which execute In parallel at ran time. In addition, threads in 
subcontexts (hierarchically nested contexts) may well be 
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Fig. 7. A UserObiect encapsulates a subnetwork of other objects into a 
single larger object with its own inputs and outputs. 
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running in parallel with their host threads in their parent 
contexts. 

UserObiects can be secured such that the user of the device 
can access only the panel and not the internals. In this form 
the Use'Obiect is almost indistinguishable from any primitive 
device. This capability allows developers to create arbitrary 
devices that can be archived in a library' for later access by 
users, who can treat these devices as irue primitives in iheii 
application. 

Threads 

Devices that are connected to each other within the same 
context form a single thread of execution. One of the in- 
herent advantages of dataflow programming is the ability to 
support multiple independent threads of execution with 
relative ease (see Fig. 8). This becomes particularly useful 
when interacting with the rest of the world, since indepen- 
dent monitoring operations ("Has thai message arrived 
yet?") can proceed in parallel with related operations. In 
typical 3GLs such operations require elaborate schemes for 
enabling interrupts and related Interrupt service routines. 
Most who have deall with such code as inline text can attest 
to the difficulty of maintaining that code because of the diffi- 
culty of easily recreating the relationship between parallel 
operations once the code has been written. 

Several devices were developed especially for thread-related 
activities. One of these is the Exit Thread device, which termi- 
nates all execution for devices on that same thread when 
encountered. Another is the Exit UserObiect device, which ter- 
minates all execution on all threads within the context in 
which it is encountered. 

Certain devices have the ability to elevate a threads priority 
above the base level to guarantee that thread all execution 
cycles until completion. One such device is the Wait For SRQ 
device (SRQ = service request ). which watches a specified 
hardware IA I bus in anticipation of a service request. If and 
when such a request is delected, this device automatically 
elevates the priority of the subthread attached In its output 
so that all devices connected to that subthread will execute 
before devices on any other thread (within this context or 

any other coniexi i until thai subthread completes. 




Fig. 8. Any coiUext (e.g.. .1 UserObject) can contain one or more 
threads, each of which exenites Independently of all hiIhts willun 
dial context 




\— • • • 



Fig. 9. Object* A and B and the XY display will execute 10 limes 
each at run time as the iterator fires its only data output (tight side) 
10 times before firing its sequence output (bottom) The data from 
the output of X is reused Tor the last 9 of the 10 executions of A 
(active data rule). 

Although it is not specifically thread related, a similar Capa- 
bility exists for exception service. At the time an exception 
is raised (e.g.. an error occurs), all other devices on all other 
threads are suspended until an exception handler is found 
(discussed later). 

Propagation: Flow of Execution 

From an external point of view, the determination of which 
devices can execute is a simple problem of finding out 
which devices have had all of their inputs updated. From an 
internal point of view, the problem is a bit more difficult. To 
prevent infinite feedback the general rule for dataflow pro- 
grams is that each device can execute only once per activa- 
tion of the context in which the device resides. On the other 
hand, it was fell from our earliest prototypes thai hav ing 
iteration occur within some subgroup of devices in a con 
text was superior lo dropping down into a subconlexl multi- 
ple limes to accomplish the same thing, especially for 
nested iteration. 

Thus we were faced with the problem of allowing groups of 
devices to execute multiple limes within a single activation 
of a context Identification of these devices could only occur 
at run lime as they appeared on the subthread hosted by the 

primary output of an iterator. To ileal with this we devel- 
oped the virtue! context, which is defined not by Hie user 
bul by the system (see Fig. '.)). Al run time, the devices thai 
are executed on the subthread hosted by an iterator are re- 
membered. Then, jusl before the nexl filing of the iterator 
(since an iterator generally fires its output more than once 
for each execution of thai iterator), the devices in ihis 
virtual context are selectively deactivated separately from 
the other devices in the context. This allows them to be re- 
cxectited when the iterator fires again by the normal rules of 
propagation. 

One other side effect of such iteration is that any data being 
supplied to a device within the virtual context by a device 
thai is outside that virtual context is going lo be delivered 
only once to the device within the virtual context. Thus new 
data is supplied lo the inputs as required on the first itera- 
tion, but on all subsequent Iterations no new data arrives. 
One could solve Ihis by using a special intermediary 
Sample&Hold device, but a simple extension to the rules of 

propagation turned out lo be much easier. The extension, 
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II Error Code 
It "Divide- 
by-Zero" 



Alert User lo 
Modify Input 



Msg "Unknown" 



Fig. 10. Tin- special error out put will fin- in lii-u of l In- dala null ml il' 
any prroris encountered while evaluating ihe formula. The value 
posted at the error output is Ihe error code number. This allows the 
user to decide how to handle the situation 

known as the "active data rule." says thai data from any ac- 
tive outpul of a device that is currently active (executed, but 
not yet deactivated) can be teased. This has essentially the 
same effect as the Sample&Hold but is much less error-prone. 

The goal in all of this is to create a scheme of execution that 
does not require the user to specify a sequence of execution 
with explicit device-by-device triggering as is common i" the 
world of digital design. In addition, we wanted execution to 
proceed as if the entire network were running on a multipro- 
cessor architecture with true parallelism. On a typical uni- 
processor machine only one primitive device is actually 
drawing cycles from the processor at any one instant, but 
Ihe overall effect is as if all devices both within Ihe same con- 
text level and across other levels of Ihe network hierarchy- 
are running in parallel. 

Asynchronous Operations 

For some devices we found a need to invoke certain opera- 
lions programmatically thai were peripheral to the general 
opera! ion of the device, such as AutoScale or Clear for an XY 
graph. While Ihe primary function of the graph is to con- 
struct a graph from the data present at the synchronous data 
inputs, operations such as AutoScale could happen at any 
time. A differeni class of inputs that were not incorporated 
into the general scheme of propagation was needed to initi- 
ate these asynchronous operations. Thus we developed Ihe 
control input, which when updated at run time will perform 
its assigned function within ihe associated device regardless 
of the state of any other input on the device. 



Exception Management 

Exception (error) management could have been approached 
from a number of different points of v iew, but il proved most 
effective to implement a strategy based on an optional out- 
put that fires if and only if an unt rapped exception is raised 
from within the scope of that device (Fig. 10). For primitive 
devices this allows the user to trap common errors such as 
division by zero and deal with possibly errant input data 
accordingly. In each case a number (an error code) is fired 
from the error pin and can be used by the ensuing devices to 
determine just which error has occurred. If the decision is 
not to handle the error locally, the error can be propagated 
upward with the Escape device, either as the same error I hat 
could nol be handled locally or as a new user-defined code 
and message text, which may be more informative to the 
handler that eventually owns the exception. 

Hierarchical exception handling is possible because an error 
pin can be added to any context object (UserOb|ect) lo trap 
errors that have occurred within its scope and that have not 
been serviced by any other interior handler. If the exception 
pops all the way lo the root context without being serviced, 
it generates a dialog box informing the user of the condition 
and stops execution of the model. To enable the user to lo- 
cate the exception source, the entire chain of nested devices 
is highlighted with a red outline from the root context down 
to the primitive device thai last raised the exception. 
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A Performance Monitoring System for 
Digital Telecommunications Networks 



This system collects CCITT G.821 performance statistics on CEPT 2. 8. 34. 
and 140-Mbn/s data streams and alarm data on network elements. A 
demux capability permits monitoring of tributary streams within a data 
stream. Data is collected nonintrusively by peripheral units, which are 
modular VXIbus systems. 

by Giovanni Nieddu. Fernando M. Secco, and Alberto Vallerini 



The IIP Model E35(>0 digital performance monitoring and 
remote test system is designed for surveillance of the quality 
of a digital telecommunications network and for collecting 
alarms from network elements, following lite guidelines of 
CCITT Recommendation G.821. The IIP E:j">(>0 provides the 
customer with well-defined performance parameters that 
tell how the network is doing on a statistical basis, and 
whether a failure has occurred in a network element. 

The actual network monitoring is performed by devices 
called peripheral units, which continuously monitor the 
telecom links nonintrusively. The peripheral units scan the 
PCM streams at the four main bit rales in the European 
(CEPT) hierarchy (2, 8. 34, and 140 Mbits/s), looking Tor 
alarms and binary errors, and computing Ihe G.821 
performance paramelers. 

Data produced by Ihe peripheral units is collected by a first- 
level processor, an HP iKIOO Series 4(10 workslalion, which 
stores die data in a relalional database. The first level proces- 
sor also provides for configuration of ihe peripheral devices 
and presents Ihe retrieved data and alarms to Ihe user. 



Digital Network Quality 

Digital networks have had and are slill having spectacular 
growth, constantly adding newer and more sophisticated ser- 
vices to customers. In many European countries, it is now 
possible for a customer lo lease 2-Mbil7s digital lines to build 
a private network, ll is very common lo lease 64-kbil/s perma- 
nent or packet circuits. In Ihe most industrialized countries, 
practically every large company has its own privale network. 

Network customers demand and pay for a specified quality 
of service. The CCITT In Its Reeommendaiion G.821 Starts 
with the definition of network quality parameters (see defi- 
nitions below) and gives end-to-end quality objectives (see 
Table I) for a 27.500-km. 04-kbil/s Circuit called Ihe Hypol heli- 
cal Reference Connection (1IRX). Fig.l shows Ihe functional 
representation of die 1IRX. 

The following quality parameters are defined in G.821: 
Errored second (ES): a second with at leasl one error 
Severely errored second (SES): a second With a bit error 
rate (BER) worse than 10 :) 
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FiR. 1. Functional representation of the Hypothetical Reference i 'oiiuccikiii I HUN i defined in < ' 'ITT Recommendation LB = local 

exchange PC = primary renter. SC = secondary center TC tertiary center. ISC = international switching • -enter 
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• Degraded minute (DM): a Collection of GO non-SES with a 
BER worse than 1CH 3 

• Unavailable seconds (UAS): a period that starts when at 
least 10 consecutive SES are counted and ends when 10 
consecutive non-SES are seen. I'AS includes the first 10 
SES and excludes the last 10 non-SES. 

CCITT Recommendation M.550 (M-series recommendations 
arc addressed to service management ) tells service provid- 
ers how the objectives of Table I are lo be allocated inside 
the transmission network. The end-to-end objectives of 
Table 1 are partitioned according to the quality classification 
of the circuit (high, medium, or local grade). Table II gives 
the percentage of the objectives that must be allocated for 
each circuit classification. For the local-grade and medium- 
grade circuit classifications, the allocated percentage of the 
objectives is independent of the circuit length. while for high- 
grade circuits, the allocated percentage (40% in Table II) must 
be scaled according to the length of the circuit. For example, 
for a high-grade circuit 2,500 km long, the allocated percent- 
age of the objectives will be 40 x (2,500/25,000) = 4%. Annex 
D of G.821 suggests a method for computing all parameters 
originally defined al 64 kbils/s for higher bit rates, by 
measuring errors al the higher rates. 



Table I 

End-to-End Quality Objectives 

Quality Parameters Objective 

(Maximum Percentage 
of Time) 

Degraded Minutes (DM) 10 
Severely Errored Seconds (SES) 0.2 
EiTored Seconds (ES) 8 

Table II 
Allocation of Objectives 

HRX Circuit Quality Classification Percentage of 

Objective 

Local (each end) 15 
Medium (each end) 15 
High 40 

As an example of the allocation of objectives, suppose I hat 
the path whose quality parameters are lo be measured starts 
at a local exchange, ends at a secondary center, and passes 
through a high-grade circuit 1.500 km long. This means that 
the sum of a local-grade circuit, two medium-grade circuits, 
and a high-grade circuit must be allocated. According to 
Table II, the allocated percentage is 15 + 2 x 15 + 40 x 
( 1,500/25,000) = 47.4%. This leads to the following path ob- 
jectives (RPO stands for reference performance objective): 

RPO(DM) = 10%', x 47.4% = 4.740%, 
RPO(ES) = 8% x 47.4% = 3.792% 
RPO(SES) = 0.2% x 47.4% = 0.095%. 

TMN Architecture 

The architecture of the IIP E3560 follows as closely as 
possible the architecture proposed in Recommendation 
M.30 of the C CITT Blue Book Series. M.30. which is better 



known as TMN (Teleconununications Management Network), 
establishes the building blocks and data links that should be 
employed in the design of a network whose aim is the man- 
agement of the telecomm network.* In Recommendation 
M.30, four blocks are identified (see Fig. 2): 

• Network elements (NE) represent the devices that make up 
the telecom network. It is assumed that an NE is "intelli- 
gent" enough lo have the possibility of generating and trans- 
mitting some kind of information useful for network man- 
agement. All NEs produce for external use some sort of 
internal alarms, both urgent and nonurgent. These are rep- 
resentative of internal faults. Urgent alarms indicate a need 
for immediate maintenance. Alarms can be displayed in a 
centralized operation and maintenance center to help net- 
work personnel understand where faults have occurred and 
to minimize the need for manned offices. 

• Operations systems (OS) are the blocks where the network 
management lakes place. They can be thought of as com- 
puters thai receive a large amount of data from the network 
and provide for its elaboration and for Ihe generation of 
dala useful for management purposes. 

• Mediation devices (MD) provide the links between Ihe NEs 
and the OSs. Their main functions are protocol conversion. 
Information conversion and storage, data buffering, and fil- 
tering. These blocks can be absent if the NEs are powerful 
enough lo manage the data link with the OSs. 

• Recommendation M 30 has recently been renamed M 3010 




Fig. 2. Simplified physical architecture of the Telecommunications 

Management Network (TMN) specified in cciTT Recommendation 

M.30 (now M3010) NE = network element, OS = operations sys- 
tems. MD = mediation devices. WS = workslalioas. DCN = digital 
communications network. LCN = local communications network QA 
= y adapter, a protocol converter. Qx and Q3 are types of rlata link 
protocol stacks. F, X, ami M arc different types of interfaces. 
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Fig. 3. HI' EI3660 digital performance monitoring system architec- 
ture. PU = peripheral unil. M = modem. DCN = digital communica- 
tions network. The HP B3560 architecture is modeled on Lhe TMN 
architecture shown in Fig. 2. The first -level processor is an HI' 9000 
Series 4(10 workstation. 

Workstations ( WS) display data elaborated by the OSs in a 
form understandable by humans. 

These blocks and the functions lhey perform must not nec- 
essarily be though! of as separate entities. An NE can have 
functions typical of an MD. and an MI) can have functions 
typical of an OS or a WS. 

HP E3560 Architecture 

In the HP E3560 architecture, which is shown in Fig. 3, lhe 
peripheral units play the role of NEs. They are not actually 
part of the telecomm network, since lhey don't provide for 
the transfer of voice or data, but nonetheless they are a 
source of management information. 

The first-level processor acts as a mediation device (MD) 
with OS functions. It collects data from the peripheral units 
and stores it, and it provides basic processing aimed at lhe 
generation of performance alarms following ('('ITT Recom- 
mendation M.550. Finally, it is an entry point into the system 
through the window-based human interface. 

The links between lhe various blocks of lhe architecture are 
particular OSI stacks named Qx and Q3, Ox is lhe link used 
to transfer data between the peripheral units anil the first- 
level processor. Q3 is a complete seven-layer IS( I ( Interna- 
tional Standards ( Irganization) OSI (Open Systems Intercon- 
nection) stack, based on X.25 or Ethernet protocol in Ms 



three low er layers. Q3 is defined by CCTTT Reconunendations 
Q.96T and Q.962. 

Qx. defined In Recommendation G.773. is also called the 
"short stack." since not all of the OSI layers are present. Two 
profiles or stack configurations, called Al and A2. have been 
proposed by the CCTTT. Both are missing OSI layers 4. 5, and 
6. which are replaced by some mapping functions that act as 
a sort of "short circuit" between layer 7 service requests and 
layer 3 services. Both stacks have the same layer 7 compo- 
nents definition: CMISE (ISO 9595/9596, CCTTT X.710/711), 
ROSE (CCITT X.219-X.229). and ACSE (CCTTT X.217-X.227). 
The mapping functions provide some basic layer 6 services, 
such as the encoding and decoding functions, according to 
the basic encoding rules of C'CrTT X.209. 

The two profiles differ in layers 1. 2. and 3. as shown in Fig. 4. 
Profile Al. which is used in the HP E3560. uses RS-4S5 as 
the physical layer, IIDLC-NRM as layer 2, and ISO 8-173 as 
layer 3 (of the possible three subsets of ISO 8473. the HP 
E3560 implements the so-called "NULL IP"). Profile A2 is 
based on an Ethernet link. 

In the IIP E3560. Qx/Al constitutes the data link between the 
first-level processor and the peripheral units, or in TMN ter- 
minology. Qx/Al is the LCN (local communication ueiwork). 
Since the network topology is point-to-multipoini. the rela- 
tionship between the first-level processor and the peripheral 
units is of a master-slave type. The peripheral units are con- 
tinuously polled by the first-level processor, which acts as a 
primary station. Only when a peripheral unit receives the 
polling request (or the RR frame in HDLC terminology) is it 
allowed to send one [jacket of data to the first-level proces- 
sor. Packet length is limited to 256 bytes (one octet in the 
HDLC frame) and packet segmentation is not allowed. 
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Fig. 4. The CJx data link protocol stuck as defined in < '(TIT Rccniii- 
mondalion (1.773. Two profiles. Al and A2, are permitted Profile Al. 
which is used iii the HI' E3560, uses BS-485 as the physical layer, 
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The number of peripheral units thai can he handled by a 
first level processor is limited hy I he addressing capability 
of Ihe IIDLC protocol, which, as staled in (i.77;J, is 251. ( )ne 
byte is used to address a secondary station, and address 
values (Kilt and FFh are reserved lor the "no stalion" and 
"all Stations (broadcast )" addresses. On Ihe other hand, the 
number of peripheral units thai can be physically connected 
to a first -level processor is al most 30 because of charge 
limitations of the RS-485 bus. 

Remote Links 

In developing tin- IIP E-'i">(iO, another protocol limitation had 
to be overcome: as implied by its name, the l.CN cannot 
span more than a few hundred meters, so the l.CN is useless 
for connecting reunite peripherals to the first -level proecs- 
son For cost reasons, it is unacceptable to place a first-level 
processor at each site where a peripheral unit is located, so 
a solution involving modems and leased lines had to be 

found. 

The HP E3560 solution for remote links takes Ihe form of 
I wo additional peripheral unil boards: the communication 
board and Ihe communication controller board. The commu- 
nication controller can drive up to eight communication 
boards, each of which has two RS-232 ports capable of driv- 
ing an external modem. One of the communication boards is 
connected to the R&486 bus. Installed in a local peripheral 
unit, a set of these boards acts as a router between the main 
bus and the remote peripheral units, as shown in Fig. 3. One 
router section can drive up to Hi remote peripheral units or 
up lo Hi remote addresses. The distribution of the addresses 
among the RS-232 polls is customer-defined, ranging from 
Hi addresses driven by a single port (using only one commit 
nication board) lo 16 addresses, each driven by a single port 
(using eight communication boards). 

Al the remote site, Ihe peripheral unit physically connected 
to the modem (called the remote master peripheral unit ) 
acts as a repeater, locally regenerating the RS-185 bus. 
Throughout the remote links. Ihe protocol front layer 2 up is 
still Qx. so What we have obtained is Ihe extension of Ihe 
protocol al Ihe expense of redefining the physical layer for 
only part of Ihe transmission path. 

First-Level Processor Interface 

On the first-level processor side of the RS-485 bus. an 
HP RTI (real-time interlace) card Interfaces the processor to 
the peripheral units. This board interfaces to the I/O bus of 
the HP 9000 Series 400 workstation and accepts inputs from 
SBX boards purchased from HP or other vcndors.t No out- 
put interface is provided. From a protocol point Of view, the 
first-level processor's Qx stack is split into two parts: layers 
I and 2 are implemented in the RTI card, while Ihe remain- 
ing part runs in the HP-UX* environment. In Ibis way. the 
stack section most affecled by typical real-time problems 
runs on a dedicated processor with a real-lime multitasking 
kernel ( the HP RTI card uses the pSOS+' M operating sys- 
tem). Communication between the two pails is handled by 
the HP-UX device driver mechanism. 

! SBX (Standard Bus eXiensinnl is an industry-standard bus The SBX boards used m the HP 
E3560 til into the SBX connector on the HP PTH card and have serial norts far RS-485 commu- 
nication The HP 94185A 2 channel senal SBX card is used in the HP E3560 



First-Level Processor 

The fjrSt-level processor's main task is the collection of data 
produced by the monitoring activities of Ihe peripheral units. 
This data, divided into the two classes of performance data 
and alarm data, is processed and stored in a relational SQL 
database for further analysis and historical tracing. Alarms 
are displayed on the screen to alert maintenance personnel. 
To help Ihe operator in problem solving, other software is 
provided for reporting and fault localization exploiting the 
deiiiux capabilities available in the peripheral units. The 
first-level processor can have a Q:i connection lo a second- 
level processor or an existing OS. 

The other important first-level proc essor function is periph- 
eral unit management Through a simple-louse human inter- 
face based on X Windows, it is possible to set up Ihe boards 
in the peripheral units and Selectively start and slop the 
monitoring operations. 

In addition to Ihe normal software environment provided by 
HP 9000 Series 400 workstations (HP-CX and X Windows), 
the fust -level processor's software is based on the HP < Ipen- 
Vievv platform. 1 The services offered by IIP < ipenView are 
exploited both from Ihe programmer's side (easy and well 
defined communication between tasks, object-oriented ap- 
proach, etc.) and from the user's side (object management 
through Ihe use of maps). 

Peripheral I 'nits 

The IIP E3500 peripheral unil can be considered a network 
element ( NE) whose main purpose is lo Collect status and 
network quality parameters from other NEs. Alarms are 
collected directly and indirectly front the NEs and sent lo 
Ihe first-level processor lo be processed. Quality parameters 
are collected indirectly from the NEs. processed according 
to CCITT G.82I, and sent to the rtrst-levei processor. 

The peripheral unit is designed to be inserted both function- 
ally anil structurally into Ihe telecomm environment, specifi- 
cally in the digital transmission area. The digital transmis- 
sion area is Ihe pan of a telecomm system that deals with 
digital information transport by means of equipment such as 
multiplexers, line terminals, regenerators, add/drop multi- 
plexers, cross connections, digital radio relays, and so on. 
This area and the digital switching area are Ihe building 
blocks of a digital network. It is reasonable lo say that most 
of today's telecomm equipment is digital and much of it uses 
fiber Optic media to transport signals all over the world. 

Peripheral t'nit Description 

The peripheral unit is built to solve Ihe problem of alarm 
collection and analysis for a large variety of alarm types. 
Different physical interfaces are available, including current 
loop, voltage sensing, and open or closed contact sensing. 

Data streams from 2 Mbils/s up to I 10 Mbits/s can be ana- 
lyzed both intrusively and nonintrtisively. This is achieved 
hy means of high-impedance probes connected lo the data 
si reams at protected monitoring points according to CCITT 
G.772. or by taking the signal directly from standard moni- 
toring points that are sometimes already present in the net- 
work central office Typical network alarms collected include 
loss of signal, AIS (alarm indication signal), loss of frame 
alignment, and so on. It is also possible to count events 
coining, for example, from radio relay equipment that Hags 
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block parity errors or forward error correction ( FEC I code 
interventions. These events are also processed and used to 
compute the G.S21 parameters. 

Tte peripheral unit is modular for flexible configuration. 
Many different types of boards c an be mixed in I he periph- 
eral unit cardcage according to the needs of the application 
The boards and backplane conform to the VXIbus standard.- 1 
and each board is a complete instrument. Thus, expanding 
existing measurement capabilities is simply a matter of du- 
plicating existing boards, while adding new functionalities is 
a matter of installing new boards and updating the software. 
Vp to ten application boards and up to three comnuinicai it m 
controller boards can be installed in each peripheral unit. 
The peripheral unit can easily be installed in a central office 
thanks to its standard lM-inch width and relatively small 
depth (11.8 in). There are two power supply types, one for 
de-powered central offices (— 48V, -60V) and one for ac- 
powered offices ( lOOVac. 240Vac). 

The peripheral units are interconnected by an RS-485 bus. 
which is the physical layer of the TMN Qx protocol. Vp to 
30 peripheral units can be physically inserted in the same 
RS-485 bus. This bus is shared by the first-level processor, 
which is the primary station and polls the peripheral units 
(secondary stations). It is possible, using the dedicated com- 
munication boards described earlier, to accommodate more 
than 30 peripheral units. The same boards can also be used 
to connect remote peripheral units through modems on 
leased lines or service channels. 

Fig. 5 gives an overview of the cardcage. The cardcage can 
house up to 16 B-size VXIbus or VMEbus boards. Thirteen 
slots have all of the VXIbus lines and form a VXIbus subsys- 
tem, while the last two slots have only the VMEbus lines. 
According to the VXIbus Standard, the first slot is for the 
slot 0 board, which together with the processor board is the 
resource manager of the cardcage. Slot 0 has four peripheral 
unit communication puns called .11, .12, J3, and J4. Jl is 
RS-485, .13 is either RS-232 or RS-485, 34 is RS-232. and .12 is 
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Fig. 5. HP B3560 peripheral unit cardcage organization, 



a passive connector that can be paralleled With Jl or J3 and 
acts as a tee connector for the communication bus. A local 
maintenance terminal can be connected to J4 for local 
management and maintenance. 

A requirement for the cardcage is that not only the boards, 
but also the power supply and the fans, must tie easily re- 
placed- This is considered important for a telecomm NE 
l>ecause it is common for all of the parts of a telecomm sys- 
tem to be easy replaceable .Another important feature of the 
cardcage is cable management. In some configurations DBOK 
than 81) coaxial cables must be managed in the cardcage. 

The power supply provides the following resources: +5V at 
20A. + 12V at 3 A. -12V at 3A. -5.2V at 10A. and -2V at 6A. It 
is also responsible for generating the VXIbus reset and 
powerfail signals, anil it can maintain its spec ified output 
capacity for up to 20 ms of power line failure, permitting the 
system to work without Interruptions. 

The peripheral unit meets the requirements of 1EC 750 re- 
garding safety. CISI'R 22 Class B for radiated emissions, and 
IIP environmental specifications (ETM CI "Office"). 

Peripheral Unit Boards 

The system is organized to house VXIbus or VMEbus boards. 
.Ml of the application boards are VXIbus register-based, B-size 
boards. They use a common bus interface unit implemented 
in an ASIC (application-specific integrated circuit ). Every 
board can run a self-test to determine its status according to 
VXIbtiS rules. A useful feature is self-configuration, which is 
implemented using the VXIbus M00ID lines and the standard 
registers provided in the VXIbus A16 address space. Every 
board has its own address and a model code that represents 
its functionality. This allows the processor that controls the 
peripheral unit to determine the cardcage configuration and 
any board's status automatic-ally. 

The system boards are the slot 0 board and the processor 
board. The slot o board is required by the VXIbus standard 
to provide common resources to VXIbus subsystem slots 1 
through 12. Slot 0 also provides the system trigger, which is 
used to synchronize the measurements, and basic system 
resources such as the system clock and the bus arbiter. The 
processor board is a VMEbus B-size board and is responsi- 
ble for raw data collection from the application boards. 
Alarms are stored in local memory waiting to be polled by 
the first-level processor, while the raw data is processed to 
obtain the 0.821 parameters which are then stored until 
collected by the first-level processor. L"p to 80 digital 
streams (this is the case for ten 2-Mbitys boards), or up to 
100 alarm points (this is the case for ten alarm boards) can 
be processed in a peripheral unit. In the case of a loss of 
communications between the first-level processor anil the 
peripheral units, all of the 0.821 records can be stored for 
Up to 12 hours; each monitoring point is alloc ated a buffer 
for 50 records, a record consisting of type of alarm, start 
lime, and slop time. The processor software can be updated 
Using a DOS-based personal computer connected to the J4 
RS-232 connector. 

The communication controller and communication boards 
are used to extend the bus to remote sites. Any communica- 
tion board can drive Iwo modems al a maximum speed of 
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9600 bite/a The communication controller is basically a pro- 
cessor hoard w ith specialized communication software and 
can control up 10 Hi remote peripheral units. 

Ml' B366Q application-specific hoards include a 140-Mbil/s 
tnonitor hoar d, a 34-Mbit/S monitor board, an K Mbit/s moni- 
tor hoard, a 2-Mbit/s monitor board, a counter hoard, and an 
alarm board The monitor hoards can recover a I '< TIT G.703 
Signal. They can analyze the Standard < CITI" (i.702 hierar- 
chy starting with 2 Mbits/s (2048 kbiis/s) or a pseudorandom 
( PRBS) signal according lo CCTIT 0.151. The 2-Mhit/s moni- 
tor hoard analyzes up to eight independenl dala st reams. 
Measurements can he made using code violations, frame 
alignment errors. CRC-4 errors, or PRBS errors. Hie 8-Mbit7s. 
:(4-Mbit/s, and 140-Mbit/s monitor boards can analyze a 
single data stream. They measure code violation errors, 
frame alignment errors, or PRBS errors. The counter board 
can count events at a maximum speed of 1 MHz. lis eight 
independenl inputs can accept signals from -5V to +5V and 
Its maximum sensitivity is 100 mV. The alarm hoard has 16 
independent inputs. When an input is set for high imped- 
ance, it can collect events from -60V lo +60V, and maximum 
sensitivity is IV. Il can also be set to measure open or closed 
contacts or current loops. 



Any of the monitor hoards can demultiplex a tributary dala 
stream inside the dala stream being processed and send it lo 
the VXIbus local bus lines. Any board in I he system can sink 
and/or bypass these lines to I he next board. This means thai 
a group of hoards, say one :i4-Mbit/s, one S-Mhil/s. and one 
2-Mbil/s, can acl as shared demultiplexers for the oilier 
monitoring boards, which can send these boards their 
signals lo he demultiplexed. 

Two special application boards are also available. These arc 
basically the standard S-Mhil/s and 34-Mbil/s monitor boards 
without the G.70-') interface. They perform the demux func- 
tion while analyzing Ihe si reams coming from the local bus. 
Tills can he economically convenient when a demux feature 
is shared among many monilored streams. 

Another common resource is Ihe scanner board, which 
contains two 4:1 analog multiplexers. The high bandwidth 
of this board allows Ihe multiplexing of signals up lo 141) 
Mbits/s. I'p lo three multiplexers can be cascaded. A scan- 
ner board can be used lo scan a group of digilal dala 
streams, connecting one al a time lo a monitor board. This 
can lower ihe cosl per dala si ream but has Ihe disadvantage 
t hat no data stream is monitored continuously. 
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Fig. 6. HP K.ir>t.t> software architecture. The software is based on I he HP < ipenView network management software 
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HP E3560 Software 

The HP B35G0 software is based on HP OpenView. 1 as 
shown in Fig. i>. 'flic :ii>|iliraiions and managers that form 
the software environment are divided into four packages: 

• Base software 

• Communication softw-are 

• Presentation son ware 

• Threshold manager software- 
Base and Communication Software 

The base software lets the user manage the peripheral units 
by acting on the manager map (Fig. 7). This is actually a set 
of maps, each exposing a particular level of detail in the 
system architecture, from a high-level view (peripheral unit 
level) down to the board level and Ihe individual monitoring 
channels inside Ihe boards. Another set of maps called the 
user map is available for surveillance ( see "Presentation 
Software," page 97). 

By selecting an object w ith ihe mouse and using Ihe ap- 
propriate menus, the system manager can set up ihe periph- 
eral units and start and slop ihe inoniioring activities. This 
feature is available both on the peripheral imit level (a sort 
Of big switch that turns on and off ihe monitoring capabili- 
ties of an entire peripheral uni! ) and on the single-channel 
level. Thus it is possible to enable or disable the monitoring 
of a single data stream or alarm input. 

The pail of the user interface noi directly handled by HP 
OpenView is managed by the ConfigA application, which 
translates user requests into the appropriate primitives and 
posts (hem to the IIP OpenView communication infrastruc- 
ture to be sent outside the workstation using Ihe Qx proto- 
cols. Since t his is not one of IIP OpenView's native stacks, 
the lask is performed by a pfOXS manager (which is part of 
Ihe communication software). The proxy manager lakes 



care of the translation between the HP Oj>enView primitives 
and the Qx primitives. Furthermore, the proxy manager 
manages all associations With ihe peripheral units and en- 
sures the correct addressing of each outgoing request. The 
proxy manager returns incoming responses to the applica- 
tion or manager waiting for them, and sends event report 
indications to the event management server (see below). 

The proxy manager also manages data link faults. The OSI 
layer 2 protocol continuously polls the peripheral units and 
can detect any disconnection resulting from line breakage, 
peripheral unit failure, or some other cause. In tltis case, it 
issues a DL-DISCONNECT request towards Ihe OSI stack's up- 
per layers. The layer 7 service element responsible for asso- 
ciations forwards this request to t he proxy manager as a 
PROVIDER-ABORT indication. The proxy manager translates 
this into a formal understandable by HP OpenView by issu- 
ing a particular event report indication to the fault manager, 
a part of the base software not shown in Fig. (». which signals 
the fault by changing ihe object's color on the network map. 

The fault manager is one of three managers that handle in- 
coming events. The other two are the alarm manager and 
the statistics manager, which receive the alarms and the 
G.821 data, respectively, from Ihe peripheral units and store 
il in ihe database. These managers use the services of the 
event management server. Each manager creates a tiller 
which is used by the event management server to route the 
various events to Ihe managers that are waiting for them. 

Since data handled by these managers requires a large 
amount of storage (customers typically ask for 1 lo 2 years' 
storage), it was deemed belter not to use the database 
embedded in HP OpenView, but to provide instead an SQL 
database, which Is also useful for report generation. Con- 
figuration information is also stored in the SQL database. 




Fin. 7. HPE3560 manager map 
(Kip level). 
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ll was a design choice thai all information pertaining l<> the 
peripheral anil is kept in the peripheral unit itself The first- 
level processor stores only logical Information related to the 
peripheral unit (e.g.. the data streams' names and creation 
dates) t hat doesn'l correspond to any physical attribute of 
the device. 

'I'he alarm manager also changes the status and therefore 
the map color of the affected object. The IIP E3560 uses the 
four colors allowed by IIP Open View. Each color is associ- 
ated with a particular status of the affected object. The four 
basic status conditions are: 

Unknown. This status means that I he object has not been 
created yet. It is known by the first-level processor, but not 
by the peripheral unii that contains it. 
Normal. The object gets this status after a successful cre- 
alion. thai is, after a create request has been issued to the 
peripheral unit and has been acknowledged by it. 
Warning. The object gels this status when an alarm indica- 
tion has been received. When the alarm is turned off. the 
object's status changes back lo normal. 
Critical. The object gels this slat us when a data link fault 
occurs, thai is, when it is no longer possible for the first- 
level processor lo acl upon the object. 

Database Management 

Database management is part of the base software. It is han- 
dled by the ConfigA application and the alarm and statistics 
managers. The database structures consist of three main 
tables: 

Configuration tables store data regarding peripheral units 
and monitored data streams. As mentioned above, only log- 
ical parameters are stored in the first-level processor, such 
as the data stream name, its creation and disconnection 
dales, and the quality parameters of the stream (see 
"Threshold Manager Soft warp" below). 



• Alarm tables store alarm source, type, begin lime, and end 
time. 

• Performance tables store performance data coming from 

the peripheral unit Each row of the table stores a record 

containing the error counts (ES. SES. DM. 1 'AS) and three 
bit error rale indicators Computed by the peripheral unit in 
slightly different ways. 

The way in which performance data is managed is critical lo 
the operation of the system. Elementary data coining from 
the peripheral units occupies a lot of disk space. Willi some 
hundred streams being monitored, disk space can be filled 
in a few months. As a compromise between data storage and 
disk space, an aggregation technique was developed to 
maintain data for a longer period at the price of reduced 
data granularity. 

The elementary records are kepi in the database for a period 
of time TJ (expressed in days), which can be defined by the 
user during the installation of the system. Each day, a back- 
ground process combines the elementary records into a 
single daily record. For G.821 parameters ( ES, SES, etc.) 
Ibis is done by simply summing all of the stored values. For 
BEH parameters, il is done by averaging all of the stored 
values. After T 1 days, the older elementary records are re- 
moved from the database. Storing the daily records before 
time Tl speeds up daily report generation at Hie expense of 
a small amount of extra storage. 

The advantage of this operation lo the user is a reduction of 
the disk space needed for the database. The disadvantage 
lies in the loss of resolution resulting from the aggregation 
process: the older data cannot be viewed with 15-minute 
resolution, but only with I -day resolution. 

The daily records are kept in the database for a period of 
time T2. At the end of each month, a second aggregation 
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lakes place, collapsing the daily records of the oldest month 
into a single monthly record. After T2 months, the oldest 
daily records are removed from the database. 

Finally, after a period of time T3. the oldest records are 
deleted from the database- 

Tl. T2, and T3 can be defined during system installation, but 
it must be realized that their values have different impacts 
on disk space. Elementary records have the highest storage 
requirements, while daily and monthly records play only a 
secondary role. Therefore, a higher value of Tl means re- 
ports with higher resolution for a longer time, but it also 
means more disk space and cost. 

Presentation Software 

The presentation software is implemented using the RcportA 
application. Reports are divided into two families: statistical 
and alarm reports, which show performance and alarm data, 
respectively. Performance data can be displayed in three 
formats: hourly (Figs. 8 and !»). daily (Fig. 10), and monthly. 
The hoiuiv display shows data as it is stored in the database 
(elementary data). The daily and monthly displays show 
aggregated data. Various reporting Options let the user make 
reports on a single data stream or on a group of data 
streams, showing absolute or percentage values. The user 
can define thresholds for ES. SES, and DM and have the 
report flag all records having one or more values over a 
threshold. Optionally, the usei can ssk foi a report displaying 
only values thai exceed system or user-defined thresholds. 

The RcportA application user interface makes extensive use 
of X Window panels and IIP Open View maps. The user's 
selections are translated into SQL queries and I he results are 
formatted in a Die and displayed. The file can also be piinled. 
The IIP E:i5t>(l design philosophy allows system users, who 
perform reporting activities, to make use of user maps. 



These contain only objects such as data streams or alarm 
inputs and are not cluttered with configuration objects 
( peripheral units, boards, and so on ), which are not pertinent 
to the surveillance task. 

Fig. 1 1 shows a typical alarm report. 
Threshold Manager Software 

The threshold manager software has the purpose of long- 
term surveillance of the monitored data streams according 
to CCITT Recommendation M.550. 

Each data stream can lie assigned quality parameters by the 
operator. These consist of a quality classification (high, 
medium, or low grade) and the type classification of the link 
(path, section, or line section). These characteristics are 
processed to produce a set of thresholds that mark the data 
stream performance limits: the higher the declared quality of 
the data stream, the lower (he limits. The calculated thresh- 
olds also depend on another variable, the operational status 
of the data stream, which can be declared as in service, out 
of service, or repaired. The software automatically sets the 
thresholds according to the operator's declarations. 

Whenever a data stream is placed under threshold manager 
control, its performance data (ES. SES, and DM values) is 
periodically read from the database. The period, called the 
step, can be defined by the user, from 15 minutes to 1 day. 
The performance data is accumulated in iIih ihresluild mun- 
ager's private registers. This process continues for a user- 
defined period of time called the reset period, ranging from 
a minimum period, which is equal to the step, to a maximum 
of one mont h. If dining I he reset periotl any one of the accu- 
mulated values crosses the calculated threshold, the thresh- 
old manager generates an alarm, which is displayed in the 
same manner as the alarms coining from the peripheral units. 
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Fig. 9. Hourly 0.821 statistical 
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Fig. 10. Daily G.821 statistical 
report. 



Recommendation M.550 classifies circuit performance as 
normal, degraded, or unacceptable. This classification takes 
the reference performance objective (RPO. defined earlier ) 
as its reference point and scales it by a factor depending on 
the circuit type to determine the thresholds of degraded and 
unacceptable performance. For a digital path like the one 
used as an example at the beginning of this article, the scal- 
ing factor for the degraded performance threshold is 0.75. 



Thus, the performance of such a path is defined as degraded 
( D) when one or more of the quality parameters ES, SES, or 
DM crosses the corresponding threshold: 

D ES = 0.75 x RPO(ES) 
D SES = 0.75 x RPO(SES) 
D DM = 0.75 x RPO(DM) 




Fig. 11. Network stream alarms 
report. 
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Demux Software 

One of the most powerful capabilities of the HP (33600 pe- 
ripheral unit is the possibility of taking a data stream con- 
nected to the peripheral unit's front panel and extracting 
one of its tributaries. The extracted data stream can be fed 
to another monitoring board, which in turn can monitor and 
recursively demultiplex the tributary. Thus, starting from a 
140-MbhVs data stream, one can demux down to the 2-Mbifs 
level. 

This capability is exploited to give three different demux 
modes: slow, medium, and fast demux (these features are 
included in the base software ). 

Slow demux can be used to monitor a selected tributary con- 
tinuously. This is nothing more than what is normally done 
with the monitoring boards, except that the controlled data 
stream doesn't come from the transmission equipment or 
the DDF (digital distribution frame), but is extracted from a 
hierarchically higher data stream. All the operator has to do 
is select a demux source, choose the Stan Slow Demux option 
in the Demux menu, and then, helped by a dialog box, ask for 
the pattern that leads to the desired tributary. An M-ACTION 
primitive is then sent to the peripheral unit, which locates 
the required resources (mainly free monitoring channels) 
and then communicates to the first-level processor the start 
of the demux action, sending back the physical addresses of 
the selected channels. These channels appear to the opera- 
tor as symbols on the map, which the operator is asked to 
name to identify the selected tributaries during the demux 
operations. It is also possible to assign a group name to the 
whole demux chain (the set. of streams that form the pat- 
terns) which makes il possible to extract the G.821 report 
with a single query. 

Fast and medium demux are fault localization tools: their 
philosophy is the same as slow demux, but they are imple- 
mented slightly differently. The idea behind these operations 
is to explore the "tributary tree" contained in a data stream 
to find possible problems. 



Fast demux starts from a selected data stream and scans the 
tree down to the 2-Mbit/s level, reporting the status of each 
tributary. If the status is not OK. the most severe alarm de- 
tected during the scanning is reported. This operation is 
very quick and is automatically performed by the peripheral 
unit. After about 10 seconds, the report is ready on the 
screen. 

Medium demux operates in the same way. hut the time dedi- 
cated to each tributary can be chosen by the operator ( from 
1 to 60 seconds). Since this results in a longer operation, the 
result is more accurate. The report also gives the I3ER 
estimated during the observation of the tributary'. 
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Women Engineers and is active in HP's K-12 educa- 
tional program in Colorado Springs She was born in 
Deer Park, Washington and enioys soccer, scuba 
diving, reading, mountain biking, camping, hiking, 
climbing, and traveling in her spare time 
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Kenneth R. Krebs 

•^^^BHB Product designer Ken Kretis 
y worked on the package de- 

sign for HP 4980A Network 
Advisor Ken has worked as 
a product designer at HP's 
Colorado Telecom Division 
since joining HP in 1980 He 
has also worked on the 
package designs lor the HP 
4953A and HP 4952A protocol analysers. Before |Oin 
log HP he worked on the design of blood processing 
sysiems at Haemonetics Corp. He received a BA 
degree m economics and a BS degree in mechanical 
engineering from Stanford University in 1 976. and an 
MS degree In mechanical engineering Irom Stanford 
University in 1980 Born in San Maten. California, 
he is married and has three daughters His leisure 
activities include soccer, woodworking, bicycling, 
and acting in a church drama group 





Davd Ballo joined HP's 
Santa Rosa Systems Divt- 
son as an R&D engineer in 
"980, when n was the S>g- 



the HP 70902/3A IF modules 
and the HP 70700A digitizer 
module, and worked on the 
svnthesized 10. modulation source, calibrator, and 
ADC of the HP 70820A microwave transition analyzer 
module After leaving the R&D lab in 1991. he served 
as a manufacturing engineer for a year, and is now a 
product marketing engineer A native of Bellevue. 
Washington, he received his BSEE degree in 1980 
from the University of Washington David is married 
Away from the |Ob. he plays bass In a klezmer band 
leastern European folk musicl. has played guitar in 
rock bands, and together with coauthor John Wen- 
dler has brewed award-winning beer He also enjoys 
sailing, cycling, backpacking, cross-country skiing, 
and photography 

John A. Wendler 

a R&D engineer John Wendler 
joined the HP Santa Rosa 
Systems Division (then 
called the Signal Analysis 
j Division) in 1981 after re- 
ceiving a pair of BS degrees 
in electrical engineenng and 
mathematics from the 
California Polytechnic State 
University at San Luis Obispo He has worked on the 
HP 70700A digitizer module and on digital signal pro- 
cessing (DSP) algorithms, firmware design, and digi- 
tal design of the ADC memory and DSP circuitry lor 
the HP 70820A microwave transition analyzer module. 
He is named as a co-inventor in a patent on recon- 
struction of sampled signals In 1987 he received an 
MSEE degree Irorri the University of Illinois at Urbana- 
Champaign. John was born In Washington, D C. He is 
married and enjoys foreign travel, backpacking, and 
brewing his own beer. 
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Michael Dethlefsen 

^-^j^ Mike Dethlefsen received 
his BSEE degree from till 
jft^t, *gm University nf California at 
Berkeley in 1 983 and joined 
HP's Signal Analysis Division 
Inow the Santa Rosa Sys- 
tems Division) Ihe same 
year He designed the third 
convener for the HP 70907A 
external mixer interface and the 321 4-MHz calibra- 
tion source lor the HP 70907B. served as a production 
development engineer responsible for the microwave 
phase-locked loops of the HP 70900A local oscillator 
module, and worked on millimeter-wave mixers and 
receivers For the HP 71500A microwave transition 
analyzer, he has done application development and 
support, particularly lot pulsed-RF measurements In 
1992 he received an MSEE degree from the University 




of California at Davis Mrke was bom m San Luis 
Ob'SOO. California He is married and is a pilot with 
an interest in aerobatics He also enjoys backpacking 
and duck hunting 

John A. Wendler 

Author's biography appears elsewhere m this section 
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Douglas C. Beethe 

^-4^^^ A senior system architect at 

/ ^ HP's VXI Systems Division, 

f ^^^B Doug Beethe was the prmn- 

■Hj^j^B pal architect for the HP VEE 

V J^^K software Several penc 

V^^^H patents results 

V I • sas 

State University and joined 
the HP Desktop Computer Division in 1979. Before HP 
VEE, he worked in thin-film and NMOS IC process 
management. He is a member of the IEEE Computer 
Society, and his professional interests include model- 
ing, simulation, and the control of physical systems 
Born in Hays. Kansas, Doug is married, lias four chil- 
dren, and lives on a 200-acre farm He volunteers for 
search and rescue activities, participates in local mu- 
sic and drama groups, and enjoys outdoor recreation, 
flying, travel, and building restoration projects. 

William L Hunt 

Bill Hunt received his BS 
degree in computer engi- 
neering from Iowa State 
University in 1980 and his 
MS degree In computer sci- 
ence from Colorado State 
University in 1989 He joined 
HP's Corvallis Division in 
1980 and is now a software 
engineer at the VXI Systems Division He was re- 
sponsible lor software development for HP VEE. On 
previous projects, he developed an MS-DOS 1/0 library, 
firmware for the HP 1 1 0 compuier. and 1/0 cards for 
HP Series 80 computers. He has a special interest in 
object-oriented programming and has published papers 
on that subject Born in Summit, New Jersey. Bill is 
married and enjoys bicycling and skiing. 
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William L.Hunt 

Author's biography appears elsewhere in this section 
84 Dataflow Architecture 
Douglas C. Beethe 

Author's biography appears elsewhere in this section 
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Giovanni Nieddu 

Gianm Nieddu is a system 
^^^^^k engineer at HP's Necsy Tele- 

■L^ communications Operation 

1 H |S professional interests 

i^jK^^f include protocols and real- 

BMf time embedded systems He 

H studied electronic engineer- 
M mg at the University of 

Padova (Padua), graduating 
in 1984 He joined Necsy in 1987 and was responsi- 
ble for the system architecture and software of the 
HP E35B0 digital performance monitoring and remote 
test system. Born in Sacile, Italy, he served in the 
Italian Alpine troops for a year in 1985. He is married 
and enjoys mountain climbing and trekking, skiing, 
and games in general 

Fernando M. Secco 

I A sysiem engineer with HP's 

^PH^^ 1 Necsy Telecommunications 

^ 1 Operation, Fernando Secco 

i\ I mg at the University of 
_7L I Padova (Padua), graduating 
^ I in 19B2 He served a year in 

I " the Italian infantry in 1983 
and joined Necsy in 1989 
after several years with Telettra SpA. He was respon- 
sible for the design of the peripheral units for the HP 
E3560 digital performance monitoring and remote 
test system Fernando comes from Piazzola sul 
Brenta, Padova He is married and has one child 

Alberto Vallerini 

^^■k Alberto Vallerini is hardware 

^^^^ system manager for the HP 

J _ fi 1 E35B0 digital performance 

I^IT monitoring and remote test 

\^ajO system Previously, he was 

• 'MP'j^^^ hardware system manager 
I for the HP 3788A error per- 
I formance analyzer He joined 
HP's Necsy Telecommunica- 
tions Operation in 1988 and has a degree in electronic 
engineering from the University of Padova Alberto 
was born in Lendinara, Rovigo. He did his military 
service as an official in the transmission service. He 
is married and enjoys reading, music, and theater 
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Chu-Sun Yen 

Chu Yen was project man- 
ager for the G-link chipset at 
HP Laboratories With HP 
Laboratories since 1961. he 
previously managed high- 
speed analog ICs. Ethernet 
transceiver and cable simu- 
lation, and infrared network 
projects, and was a design 
engineer on projects dealing with the HP 8405A vec- 
tor voltmeter and the HP 35 calculator A member of 
the IEEE, he has authored 20 professional papers on 





circuits, phase-locked loops, instruments, and com- 
munications links, and is named as an inventor in 
three patents on a sampling phase-locked loop, the 
G-link phase-locked loop, and a dc-to-dc converter 
He received his BSEE degree in 1955 from Taiwan 
University, his MSEE degree In 1958 from the Uni- 
versity of Florida, and his PhD degree in 1961 from 
Stanford University He is married and has three 
children 

Richard C. Walker 

Rick Walker is a principal 
project engineer at HP Lab- 
oratories, specializing in 
phase- locked loop theory 
and high-speed circuit de- 
sign He joined HP labora- 
tories in 1981 and has con- 
tributed to broadband cable 
modem design, solid-state 
laser characterization, and the gigabit-link project 
Born in San Rafael, California, he received his BS 
degree in engineering and applied science from the 
California Institute of Technology in 1982 and his MS 
degree in computer science from California State 
University at Chico In 1992 He has authored 16 pro- 
fessional papers and his work has resulted in six 
patents and two pending patents, all in the areas of 
high-speed links and circuit design He's a member 
of the IEEE He's also an advanced class amateur 
radio operator (WB6GVI) and a private pilot, plays 
bass guitar and five-string bluegrass banio, and culti- 
vates several dozen kinds of carnivorous plants in a 
backyard greenhouse. 

Patrick T. Petruno 

Now R&D section manager 
for link products at HP's 
Communications Compo- 
nents Division, Pat Petruno 
was project manager for the 
G-link chipset A native of 
Allentown, Pennsylvania, he 
attended Pennsylvania State 
University, receiving his 
BSEE degree in 1976 and his MSEE degree in 1978 
After joining HP In 1978, he designed bipolar transis- 
tors, Darlington amplifiers, and digital circuits, and 
served as project manager for wideband amplifiers, 
AGCs. decision circuits, counters, and multiplexers. 
He has coauthored three papers on high-speed silicon 
circuits and participates in Serial-HIPPI and ATM 
(asynchronous transfer model standards activities 
Pat is married, has two children, and serves as a Cub 
Scout den leader His interests include astronomy, 
astrophotography, swimming, and Softball 

Cheryl Stout 

Cheryl Stout has been a 
member of the technical 
staff of HP Laboratories 
since 1983 She has done 
research and design for 
gallium arsenide and silicon 
high-speed multiplexers, 
optical receivers, and the 
gigabit-link chipset She is a 
member of the IEEE and has authored conference 
papers on high-speed multiplexers and the G-link 
chipset Born in San Jose, California, she received 
her BSEE degree from California State University at 






San Jose in 1 979 and her MSEE degree from the 
University of California at Berkeley in 1983 Before 
coming lo HP, she developed optical communication 
products at Plantronics, Inc Her interests include 
mountaineering and natural history. 

Benny W.H. Lai 

Engineer/scientist Benny Lai 
joined the HP Microwave 
Semiconductor Division 
|now the Communications 
Components Division) in 
1981 He designed the HP 
HDMP-2003/4 decision cir- 
cuits and the HDMP-2501 
clock recovery data retiming 
circuit, and did circuit design and layout and high- 
speed testing for the G-link chipset He has authored 
four papers on his designs and his work has resulted 
in one retiming circuit patent and two pending patents 
on CIMT coding and a unity-gain positive-feedback 
integrator A graduate of the University ol California 
at Berkeley, he received his BSEE degree in 1982 and 
his MSEE degree in 1983 He was born in Hong Kong, 
is married, and enjoys woodworking, gardening, and 
skiing. 

William J. McFarland 

HP Laboratories principal 
project engineer Bill 
McFarland received his 
BSEE degree from Stanford 
University in 1983 and his 
MSEE degree from the 
University of California at 
Berkeley m 1985 With HP 
since 1985. he has designed 
high-speed ICs for digital test instruments in silicon 
bipolar, gallium arsenide, and hetemjunction transis- 
tor technologies, and has done research an bit error 
rate testers and pulse generators As a member of 
the G-link project, he served as technical editor of the 
Serial-HIPPI specification He is the author or coauthor 
of a dozen technical papers and is named as an in- 
ventor in two patents related to bit error rate testers. 
Bill was born in Milwaukee, Wisconsin. His interests 
include bicycling, playing guitar, and home brewing. 
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G-Link: A Chipset for Gigabit-Rate 
Data Communication 



Two easy-to-use IC chips convert parallel data for transmission over 
high-speed serial links. A special encoding algorithm ensures dc balance 
in the transmitted data stream. A binary-quantized phase-locked loop is 
used for clock recovery. An on-chip state machine manages link startup 
automatically. 

by Chu-Sun Yen, Richard C. Walker. Patrick T. Petruiio. Cheryl Stout. Benny W.H. Lai. 
and William J. McFarland 



The last decade has seen a tremendous increase in comput- 
ing power wilii only modest advances in the bandwidth of 
the data links used to interconnect these computers. Between 
1982 and 1992, the speed of a high-performance engineering 
workstation has increased from 0.5 MIPS (million instruc- 
tions per second ) to 100 MIPS, an increase of over two or- 
ders of magnitude. In that same period of time, computer 
network bandwidths have gone from Ethernet at 10 Mbits/s 
to FDD! at 100 Mbits/s, an increase of only one order of 
magnitude. In addition to faster computers, other factors, 
such as the widespread use of multimedia applications, will 
put pressure on network bandwidths, threatening to create 
an I/O bottleneck for modem computing systems. 

I'nlike computer systems, serial links cannot exploit paral- 
lelism and must run al proportionally higher rales for each 
increment in performance. At clock rates below about 100 
MHz. traditional printed Circuit board design techniques can 
be used to implement link circuitry with collections ol pack- 
aged parts. Bui as link speeds approach the gigabit-per-sceond 
range, interchip liming skews make ii impractical to build 
low-cost gigabit links in this way. Although long-haul tele- 
phone networks have used gigabit-rate data links for many 
years, these links use nonintcgrahle components and require 
adjustment and mainlenance. Such systems arc easily justi- 
fied when the cosi is amortized over millions of users but 
are loo cosily and complex for computer use. 

To support the needs of computer and other generic daia 
transport applications, the HP HDMP- 100(1 gigabit link 
(G-link) chipset has been developed. Il is the first commer- 
cially available l.l-Gbaud link interface in two chips, a 
transmitter chip and a receiver chip, requiring no external 
parts or adjustments. 

The architecture of the (Mink chipset greatly eases the job 
of I he system designer. Communication between the chipset 
and ihe user's system lakes plac e through a low -speed paral 
lei Interface. All gigabit-rate signals, with the exception of 
Ihe serial electrical data stream, remain internal to the chips 
and are never routed on the printed circuit board. Thus Ihe 
designer is able lo use standard printed circuit board design 
techniques lo deliver gigabit-rate performance. For fiber 



optic applications, the high-speed serial signals are easily 
connected to lightwave transmitter and receiver modules. 
To simplify the designer's job further, a link-management 
state machine com roller implemented on Ihe receiver chip 
insulates the user from many of the details associated with 
link Startup and error monitoring. 

The chipset was designed in HP's 25-GHz f|- silicon bipolar 
process ami Incorporates patented circuit techniques devel- 
oped at HP Laboratories, namely the encoding scheme and 
the phase-locked loop circuit. These new techniques, de- 
scribed later in this paper, represent departures from tradi- 
tional telecommunication practice and have made practical 
the integration of an inexpensive and easy-to-use gigabit- 
rale chipset. 

Overview 

Fig. 1 shows a typical G-link application supporting a full- 
duplex Interconnection between two hosts. One transmitter 
and one receiver chip are used for each end of the link. 

From the user's viewpoint, Ihe chipset behaves as a "virtual 
ribbon cable" for Ihe transmission of parallel data over serial 
links. Parallel data is serialized by Ihe transmitter chip and 
deserialized by the receiver chip into the original parallel 
form. The chipset hides from Ihe user all Ihe complexity of 
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Fig. 2. Simplified transmitter chip block diagram. 

encoding, multiplexing, dock extraction, demultiplexing, and 
decoding needed For high-speed serial dala transmission: 

The transmitter chip (Figs. 2 and 3) accepts the user's paral- 
lel data word and clock. The word-rale clock is internally 
multiplied up to the serial rale in the transmitter chip phase- 
locked loop. This high-speed serial clock is used to multi- 
plex the encoded data. The encoding algorithm, called 
ciniililioiiiil i nrersimi with master transit imi, orCIMT, 1 
creates a frame* for data transmission by appending font 
coding bits to each input dala word. The resulting frame is 
then transmitted in either normal or inverted form.- its nec- 
essary, to maintain dc balance of the serial bit stream for 
transmission over optical links of coaxial cables. This CIMT 
line code distinguishes itself by being efficient and simple to 
implement compared to other line codes such as 8B/10B. 

To support modern network protocols, the chipset allows 
the transmission of three different types of frames. Generic 
user data is transmitted with data frames. Control frames 
are the second type of frame, and are used for the transmis- 
sion of information that should be treated separately from 
data, such as packet headers. Fill Jinnies are the third type 
of frame, and are sent automatically by ihe link during 
startup and to maintain synchronization when Ihe user 
has neither data nor control information to send. 

In the receiver chip (Figs. -I and 5). the clock and frame 
alignment are extracted from the incoming data .stream with 
a phase-locked loop. The data is then demultiplexed and 
decoded back to its original par allel form. In addition to 
these basic functions, the receiver chip also includes a state 
machine controller, which performs an end-to-end hand- 
shake and provides both bit and frame synchronization. This 
handshake avoids the false lock problems that are typical 
with clock extraction circuits that accommodate a wide 
range of clock frequencies. 

An unconventional "bang-bang" phase-locked loop'' is used 
in the transmitter and receiver to provide adjustment-free bit 
retiming at very high data rates. Using the special master 
transition built into the line code, Ihe phase-locked loop pro- 
vides frame synchronization without the periodic insertion 
of special frame synchronization words. 

A very compact chip layout was achieved by using three lay- 
ers of metal and a quasi-gate-array ECL design methodology. 

' In this paper, a frame is defined as an encoded input word. 




Fig. 3. Photomicrograph of the transmitter chip 

The 68-pin surface-mount package (Fig. 6) is designed to 
maintain good performance for 1.4-GHz signals. 

The key features of the chipset are: 
. Parallel ECL bus interface 

• lb or 20 bits wide, pin selectable 

• Flag bit usable as extra data bit (17th or 21sl ) 

• CIMT encoding and decoding 

• AcAlc coupled 

• 1 10 to 1400 Mbaud serial line rate 

• On-chip phase-locked loops for transmitter clock generation 
and receiver clock extraction 

• Local loopback mode for troubleshooting 

• Single -5V ±10% supply voltage 

• 2\V power dissipation per chip (typical) 

• Can be used with liber optic links 

• On-chip equalizer for use with coaxial cable 

• Standard 68-pin CQFP (ceramic quad flat package). 

Because of the simplicity and flexibility of the G-link chip- 
set, il can be used for a wide variety of applications, includ- 
ing computer backplanes, video distribution, peripheral 
channels, and networks. 
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Fig. 5. Plioiomkrojirapii or the receiver chip. 
G-Link Line Code 

Many coding schemes have been developed to allow com- 
munication of information over various types of channels. In 
synchronous communication links, clock and framing in- 
formation mils! be transmitted along with data in such a way 
thai the dock and data can he recovered at the receiving 
end of the link. Therefore, it is necessary for the transmitted 
encoded serial hit stream to have enough embedded clock 
information for the receiver to recover the serial clock. 
There must also he some method of frame alignment so that 
the boundaries of a frame can be located at the receiver. 

In Optical links, it is desirable to ac couple the data signals 
to simplify laser bias circuitry and optical receiver design. 
This is also true in repeater design, since the components 
are commonly ac coupled. A problem with ac coupled sys- 
tems is that the baseline will shift when the transmitted digi- 
tal data is not tic balanced. This shift makes detection diffi- 
cult and degrades the system noise margin. To overcome 
this problem, arbitrary data is typically encoded before 
transmission to achieve dc balance. The receiver restores 
the data to its original form by decoding. 

In the (i-link chipset, the CIMT coding scheme performs the 
following tasks: 

The transmitter chip supplies a master transition in every 
frame for clock recovery and frame alignment at the receiver, 
l-'raines are conditionally inverted as necessary lo maintain 
dc balance. 

Information is provided in the transmitted frame about the 
type of frame transmitted and whether or not the frame was 
inverted. 

At the receiver, decoding is done lo determine what type 
of frame was received and Whether or not the frame was 
inverted. 



• If the frame was inverted al the transmitter, it is inverted 
again at the receiver to restore the information to its orign\al 
form. 

• The receiver performs error checking on portions of the 
frames to detect loss of lock. 

This method of encoding and decoding has several 
advantages: 

• Clock information is available in each frame, indicating both 
phase and frequency alignment. 

• There is no need for the user lo send any special characters 
lo indicate Ihe start of a new frame. The G-link chips perform 
frame alignment transparently. 

• There are no restrictions on the user's input bit patterns. Dc 
balance is maintained by frame inversion and a maximum 
run length is guaranteed by the master transition. 

• By checking for framing errors, the receiver can detect loss 
of lock and reinitiate the link startup process. (A discussion 
of link Startup can be found under "Startup Stale Machine 
Controller" on page 109.) 

Data is encoded by appending four extra coding bits (C-lield) 
to the input data (D-field). The serial combination of the 
D-field and the ( -field makes a frame. The user can choose 
to transmit either data frames or control frames. In addition, 
two types of fill frames are internally generated for trans- 
mission when there is no input supplied by the user or dur- 
ing startup. To maintain dc balance, data and control frames 
are either inverted or not inverted. Information about inver- 
sion and the type of frame is contained in the ('-field. I'nlike 
typical codes with fixed data width, the CIMT code can 
accommodate multiple data widths. 

The (i-link chipset is designed to transmit either 16-bit-wide 
or 20-bit-w ide data words. Both the transmitter chip and Ihe 
receiver chip have an input pin that allows the user to select 
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Fig. 6. TraiiMinllci dnp in li.H-pin ceramic quad flat package 
(CQFP). 
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the parallel word width. There is also a flag bit, which can 
be used as an ext ra data bit. A frame consisting of the D-field 
plus I he appended (.'-field is then either 20 or 24 bits long. In 
the case of control frames, t wo bits In the D-ficld are used for 
encoding, resulting in 14 or 18 bits available for transmitting 
information. The Hag bil is obtained by selecting between 
different sets of coding bits in the C-field, 

Table 1 shows the contents ol" different frames generated at 
the G-link Iransmitler for the case of 20-bit data. DAV (data 
input available) and CAV (control input available) are sup- 
plied by I he user to indicate what type of user input is to be 
transmitted. If neither data nor control inputs are available, 
a fill frame is sent. FLAG is the additional Hag bil input. DO to 
1)19 are the parallel inputs. INV is a logic signal internally 
generated on the transmitter chip that indicates whether the 
frame is lo be inverted. 



Table I 

Contents of Different Frame Types 
for CIMT Encoding of 20-Bit Data 



FLAG DAV CAV INV 



X 0 0 X 
X (I 0 X 
X I) () X 

X X 1 D 
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00 11 Control 
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Data, FLAG Low 

Inverted Data, FLAG 
Low 

Data, FLAG High 

Inverted Data FLAG 
High 



MT - Master Transition 



The C-ficld bits were chosen so that a master transition al- 
ways occurs between the second and third bits of the (.'-field. 
For data and control frames, this transition can be in either 
direction. The C-field bits were also chosen so thai the codes 



for data and inverted data frames are complements of each 
other. The same is true lor control frames. This allows the 
entire frame to be inverted with the correct C-field bits for a 
particular type of frame. 

There are two types of fill frames, referred to in Table I as 
FFO and FF1. FF0, a training sequence used during start up, 
has a single rising edge at the master transition and is a 
square wave with 50% duty cycle. The receiver's clock recov- 
ery circuit is able to lock onto this signal, extract the serial 
clock, and provide frame alignment. FF1, another I raining 
sequence used during startup, is also sent alter startup 
whenever the user does not supply inputs for data or control 
frames. FF1 is similar to FFO except that the position of the 
falling edge moves by one bit forward or backward, creating 
a square wave that, is two bits heavy (FF1II) or two bits light 
(FF1L). The decision to send either FF1II or FF1L is made 
depending on the disparity* of previously transmitted bits, 
in an attempt to reduce the disparity to zero. Since FFO is tic 
balanced and the two types of FF1 frames are sent to reduce 
disparity, fill frames are not inverted. 

Noninverted control frames have the same C-field as fill 
frames, but are distinguished from fill frames by the center 
two bits of the D-field, which are 01. Control frames are in- 
verted when appropriate, but then have a different, unique 
C-field. 

All other possible C-field codes that are not listed in Table I 
are not allowed and are considered to be errors if received. 
The receiver detects the loss of a master transition or a for- 
bidden C-field code as a frame error. This information is 
used by the receiver's state machine to derive the link sta- 
tus. In addition, if the flag bit is not used by the user, it is 
used for additional frame error checking. The flag bit is al- 
ternated internally by I he transmitter and thus alt ernation is 
checked at the receiver. 

Coding Implementation 

Fig. 7 shows a block diagram of the transmitter chip. The 
user supplies the parallel inputs D0-D19, a frame rate clock, 
the DAV and CAV inputs, and the FLAG input (optional). The 
high-speed and subrate clocks are derived from the frame 
rate clock by a phase-locked loop circuit . "System I/O" 

Disparity is the number oil s minus the number ol Os. 
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refers to oilier signals that are Involved in the link's config- 
uration and slams. RFD (ready for data) is an output indicat- 
ing to the user that the link is ready to Iransmil dala. The 
D16-D19 inputs are ignored when the user selects lb-bit 
parallel word width. 

Depending on the DAV. CAV. and FLAG inputs, the ('-field coding 
bits are generated and any necessary encoding of the D-field 
is performed. Then the ("-field antl D-field bits are evaluated 
in a sign Circuit whose output is the sign of the disparity of 
Hie frame. A separate accumulator keeps track of the dispar- 
ity of previously transmitted bits. The decision to invert or 
not to invert a frame is made based on the outputs of these 
two circuits and is indicated by the signal INV. If the signs of 
Ihe disparities of the current frame and Ihe previously trans- 
mitted bils are ihe same, INV is high and the current frame is 
inverted. If I hey are not Ihe same. INV is low and ihe frame is 
nol inverted. Only data and control frames are inverted; the 

Invert function is disabled for fill frames. The frame is serial- 
ized with a circuit that multiplexes ihe parallel inputs into a 
serial hit si ream and performs any necessary frame inver- 
sion. The output of this circuit is then transmitted across 
the serial link. 

A block diagram of Ihe decoding portion of Ihe receiver chip 
is shown in Fig. 8, Alter Startup, the serial clock and the 
framing information are produced by the receiver's clock 
recovery circuitry, allowing the receiver to recover the serial 
dala and demultiplex il hack lo parallel form. The frame 

clock is provided as an output for use in the users system. 

By examining the (.'-field hits, the ('-field decoder deter- 
mines what kind or frame has been received and whether or 
not il has been inverted. With this information, ihe D-field 
decoder restores Ihe parallel data back to ils original form. 
In addition, Ihe ('-field decoder provides DAV. CAV, antl FLAG 
information back to ihe user. These signals have Ihe same 
definitions as the corresponding transmitter inputs. The 

( ' field bits are also used by Ihe receiver's stale machine lo 
check for frame errors. 

Encoding circuitry 

Encoding on the transmitter chip is performed mainly by 

logic cells and two on-chip programmable logic arrays 
(PI.As). However, there are I wo special parts of Ihe frame 
Inversion function, Tin- UTS) is an analog sign circuit which 



determines whether a frame has more high or low bits The 
second is an accumulator which keeps track of the disparity 
of the previously transmitted data 

The sign circuit on the transmitter consists of one differen- 
tial pair per bit, a summing circuit, and a comparator. To 
prevent errors in determining a frame's sign, it is uuportant 
for the differential pairs to have matched current sources. 
Therefore, each differential i>air is supplied by two current 
sources from an array of current sources laid out in com- 
mon centroid fashion. This reduces die effects of process 
and temperature gradients on the value of each pair's com- 
bined current source. In addition, large-geometry resistors 
are used to improve matching of the current sources. 

The currents are summed at shared collectors through resis- 
lors. creating a differential voltage proportional lo the differ- 
ence between the numbers of Is and 0s lit the frame. When 
there are more Is than (Is. this voltage is positive; when 
there are more Os than Is. it is negative. This voltage then 
drives a comparator, which produces a high or low logic 
signal depending on the sign of the input voltage. This 
method of determining Ihe sign of a frame is simpler and 
faster than a digital solution. 

The accumulator circuit keeps track of Ihe disparity of pre- 
viously transmitted bits. Ii is Implemented with a ti-bit up/ 
down counter. To relieve liming constraints, the counter 
operates on two bits at a time. This allows it to operate at a 
clock rate that is half the serial output rate. 

The counter can count from all (Is lo all Is and is reset at 
startup (0 the midpoint, which is considered a balanced 
stale. The range of this b-bit counter is then -32 to +31 bits, 
where 0 is the balanced state. With two input bits, there are 
four possible combinations: 1 1 which has a disparity of +2 
bits, DC which has a disparity of -2 bits and 01 or 10 which 
are balanced with zero disparity. Since we only need to 
count up or down by multiples of 2. we can allow one bit of 
I be counter range lo correspond lo a disparity of 2 bits. 
Thus the effective counter range, in bits of disparity, be- 
comes -64 bils lo -t-tili bits. The woi-sl-ca.se disparity thai can 
OCCUr with this coding scheme is ±-'51 bits, which is well 
wilhin the range of Ihe Counter, The mosl -significant bit of 

the counter is compared wiih the output of the sign circuit 

tO decide whelher lo invert the frame. 

Accumulating two bits at a time is Ihe most convenient ap- 
proach. If the counter were lo operate on one bit at a lime, il 
would slill have to count either up or down and one hi! Of 

the counter range would correspond to one bit of disparity 

Thus. Ihe range of a (Mil counter would be -32 to +31 bils of 
disparity, which would not have enough margin beyond the 
worst-case disparity of +31 bits. A higher-order counter 
would be required, and il would also have lo run at the full 
serial output rate, resulting in increased power consumption. 

tf the Counter were W operate on four bils at a lime, it 
would have Ihe benefil of running at one fourth of Ihe serial 
rale, but il would have lo COUTH up and down by I. up and 
dow n by 2. or remain unchanged. < die bil of Ihe counter 
range could correspond to two bits of disparity as in Ihe 

case Implemented, but the counter design would be more 

complex. 
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Phase-Locked Loop 

In a serial data link, I he clock signal is not explieiil.v lians- 
mitted. Inn is instead implied by I he transitions of Ihe dala 
Stream, By examining the transitions in lhe data stream with 
a clock extraction circuit it is possible lo create a replica of 
the original clock that was used to transmit the data This 
recovered clock can theil be used to sample and restore the 
potentially degraded analog input. 

Many high-speed clock extraction techniques exist, but most 
have been developed for long-haul telephone applic ations. 
Telecom systems are designed to maximize the distance- 
bandwidth product of the link. This criterion minimizes both 
Ihe number of physical repealer sites and the number of 
libers that have to be installed in a given nm. As a result, a 
much higher premium is placed on clock-extraction perfor- 
mance than on cost -effectiveness. These objectives have 
made this class of clock extraction techniques unsuitable for 
datacomm applications. 

Traditional Telecom Clock Extraction Circuits 

Fig. 9 shows a represent alive clock extraction and data re- 
timing circuit that is used for high-bit -rale telecom sy stems. 
The incoming analog dala stream is split into two parallel 
paths: the clock extraction chain and the data retiming path 

Because an NRZ (nonreturn to zero) data stream does noi 
have a spectral component at the clock frequency, some 
nonlinear process uiiisl be used to derive a clock signal 
from Ihe dala si ream. In the typical circuit of Fig. !l. a time 
derivalive is applied, followed by an absolute value function. 
This combination of elements creates a narrow unidirec- 
tional pulse for every transition of the data. This new wave- 
fonn contains a spectral component at the clock frequency 
Once the clock component has been created, it can be iso- 
lated either by a filter, typically implemented wiih a SAW 
(surface acoustic wave) device, or by a phase-locked loop. 

There are two problems with this configuration. The firs! is 
thai, although the circuit extracts the correct clock fre- 
quency, il does not extract Ihe correct phase. There is a 
large phase shift between Ihe input dala and Ihe recovered 
clock. The phase relationship between Ihe clock and Ihe 
dala must then be adjusted somehow to compensate for 
process and temperature variations. The second problem is 
thai the creation of narrow pulses requires high circuit 
bandwidth. This is often the speed-limiting faclor for giga- 
bit-rale clock recovery circuits. 



G-I.ink Solution 

A design goal of Ihe (Mink chipset was lo eliminate all exter- 
nal pans and user adjustments and effectively hide Ihe sys- 
tem complexity from the user through monolithic integration. 
The clock extraction circuit was most Impacted by these 
requirements. To achieve these aggressive goals, a new 
phase-locked loop circuit was developed based on a binary- 
quantized ("bang-bang") phase detector, 

The phase-locked loop circuit used in the Clink chipset (see 
Fig. 10) works hand in hand with the < IMT line code lo 
avoid both the phase adjustment problem and Ihe band- 
width requirement of ihe traditional techniques, in this cir- 
cuit, the incoming data splits into two paths (just as in the 
traditional telecom approach). Instead of a complex phase 
detector, which is potentially mismatched in delay to the 
reliming latch, two matched latches are used at the front 
end of Ihe circuit. One lalch is used for retiming and ihe 
other for phase detection, Because both latches are laid out 
identically on Ihe chip, their delays are well-matched. 

The two latches are driven by the VCO through a comple- 
mentary buffer. If the VCO is properly aligned, Ihe top latch 
samples the center of lhe dala cell on rising edges of Ihe 
clock while Ihe lower latch samples Ihe data transitions on 
the falling edge of the clock. 

Because the (Mink line code provides a guaranteed transi- 
tion ai a fixed, defined location in every frame. Ihe sample 
of this transition can be used as an indication of the loop 
phase error. The V('( ) output is divided by either 20 or 24, 
depending on the selected word width, lo produce one sam- 
pling pulse per frame. Thai clock pulse is used lo lake a 
sample in Ihe v icinity of the master transition so thai a 
phase update is generated, once per frame, indicating 
whether the VCO is early or late wilh respect to Ihe master 
transition. Assuming a rising master transition, as show n in 
Fig. 1 1, if the VCO is too high in frequency. Ihe sampling 
point drifts to the left of ihe master transition and a low 
value is sampled. If the VC( 1 is too low, the sampling point 
moves to Ihe right and a high value is sampled. This circuit 
then produces a one or zero indication from the phase detec- 
tor that tells whether Ihe VCO is early or late with respect lo 
the incoming dala 

Since Ihe fastest operating element in this circuit is a lalch 
operating at the serial rale, this circuit is usable up lo the 
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highest frctiucncy at whic h a given process is capable of 
making a functioning latch. In addition, the circuit inher- 
ently provides excellent phase alignment hot ween the VCO 
and the data. Note that the output of the phase detector latch 
is not linearly proportional to the loop phase error, but is 
instead a binary -quant i/.ed representation of the error. This 
characteristic renders the loop equations nonlinear and re- 
quires unconventional design methods (see "Bang-Bang 
Loop Analysis," page 1 10). 

False Locking and Frame Synchronization 

During initial link startup, it is necessary to ensure that the 
phase-locked loop correctly determines the frequency of the 
incoming data and finds the location of the master transition. 

In many clock extraction circuits, the clock frequency is 
extracted from a coded, random data stream. A common 
difficulty with this approach is the problem of (he phase- 
locked loop locking onto wrong frequencies that are har- 
monically related to the data rate. To avoid this problem, 
most systems limit the VCO range so that it can never be 
more than a few percent away from the correct frequency 

A narrow-band VC( ) using external components was not 
consistent with the goal of building a completely monolithic 
chipset. Integrated oscillators rely on low-tolerance IC com- 
ponents and arc typically limited to ±30% toleratice on the 
center frequency. For customer flexibility, it was desired to 
extend the oscillator range to cover at least an octave. This 
range, in conjunction with digital dividers, allows the (i-link 
chipset to operate over a range of 1 10 to 1400 Mbaud in four 
bands. 

A second design problem is frame synchronization. At the 
receiver, some method must be employed to determine the 
boundaries between frames so that they can be properly 
deserialized back inlo the original parallel words. The (i-link 
chipset establishes and monitors frame synchronization by 
using the embedded inasler transition. Unlike other links, 
the (i-link chipset allows the Continuous transmission of 
unbroken streams of data, without the insertion of special 
frame synchronization words. 



Startup State Machine Controller 

To eliminate the problems of false locking anil frame syn- 
chronization, the G-link chipset uses a startup state machine 
and the special training fill frames. 

Because the internal VCO is capable of operating over 
nearly a 3:1 range of frequencies, a frequency detector is 
necessary lo avoid false locking problems. The frequency 
detector operates only when simple square-wave fill frames 
are being sent. A conventional sequential frequency detec- 
tor, built of two resettable flip-flops, determines the sign of 
the frequency error. When the phase error is less than ±22.5 
degrees, the output of the phase detector is used. Otherwise, 
the loop filter is driven by the frequency detector output. 
Because the frequency detection circuit cannot operate on 
data frames, the state machine controller must disable the 
frequency detection circuit before allowing data to be sent. 

Neither node of a duplex link can achieve lock unless the 
opposite side is sending special Till frames. Neither side of 
the link can stop sending fill frames and start sending data 
unless the other side has successfully achieved lock. The 
state machine uses the two distinct fill frames FF0 and FF1 
to allow one side of the link to notify the other side of its 
current locking status. This guarantees that fill frames will 
be sent whenev er needed to restore lock, and only as long 
as necessary to achieve lock. 

As described previously. FFO is a 150% balanced square wave 
with equal numbers of "0 and 1 bits. FF1 consists of two 
modified square-wave patterns. These two patterns are used 
as needed to maintain dc balance on the link. Both FFO and 
FFI have a single, rising transition, which is in the same 
position in the frame as the master transition of data and 
control frames. The rising edge of the fill frames is used ini- 
tially to establish an unambiguous frame reference. After 
initial lock, the master transition of the data frames is used 
to maintain frame lock. 

Fig. 12 shows the stale machine handshake procedure for a 
full-duplex link in greater detail. Both the near and far ends 
of the link independently follow the stale diagram of Fig. 12. 
The three slates are defined by the stale variables STATO and 
STAT I. At power-up. each end of the link enters the sequence 
at the arc marked "Start." 
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Fig. 12. Stan- inai-him- handshake procedure fur a full-duplex link, 
Showing the values of the state variables STATO and STATI ((1.0. etc ). 
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Bang-Bang Loop Analysis 



A simplified version of the clock recovery phase-locked loop of the G-link chipset 
is shown m Fig 1 Only the transition sampling latch is shown, and the input is 
assumed to be a square wave at the same frequency as the VCO 

The VCO is controlled through a loop filter that consists of the sum of an integral 
signal and a proportional signal Because the phase detector is quantized, the VCO 
frequency switches between two discrete frequencies, causing the VCO to ramp 
up and down in phase, thereby tracking the incoming signal phase 

If the loop is properly designed, the system can be considered to be composed of 
two noninteracting luops These are the paths labeled proportional branch and 
integral branch In Fig 1 The first loop includes the connection of the phase detec- 
tor to the VCO input through a proportional attenuator, while the second loop 
drives the VCO through an integrator. 

The proportional signal tunes the VCO. causing the output of the phase detector to 
switch rapidly between Is and Os at a fairly high frequency. Other than the dc 
component, the bulk of the phase detector output signal spectrum falls outside the 
effective passband of the integrator branch of the loop. Thus the integrator branch 
operates on just the dc component of the phase detector output Its jab is to servo 
the center frequency of the VCO so that the two discrete VCO frequencies pro- 
grammed by the proportional input will always bracket the frequency of the in- 
coming data signal This frequency adjustment occurs so slowly that it does not 
materially affect the operation ot the high-frequency bang-bang portion of Ihe 
loop. 

Proportional Branch 

To simplify the analysis of the first branch of the loop in Fig. 1. the integrator 
output can be replaced with a constant reference voltage so the proportional tuning 
input will cause the VCO to bracket the incoming frequency The VCO will then run 
at two discrete frequencies: at a frequency slightly higher than the incoming data, 
thereby advancing the phase, or at a lower frequency, thereby retarding the phase 

If the incoming frequency is midway between these Iwo discrete frequencies, the 
loop will switch between the two frequencies with approximately a 50% duty 
cycle. If the incoming frequency is slightly higher than the nominal VCO center 
frequency, the duty cycle will shift such that the loop will spend a higher percent- 
age of time at the high frequency than at the low frequency In general, it can be 
shown that the duty cycle present at the output of the phase detector is propor- 
tional to the difference in frequency between the incoming signal and the nominal 
VCO center frequency. 

Integral Branch 

The second branch of the loop contains the integrator. Because the integrator 
effectively filters out the oscillatory portion of the phase detector output and only 
reacts to the average value of the phase detector output stream, the proportional 
branch of the loop can be ignored here by replacing the phase detector with a 
virtual frequency detectoi The integrator extracts the dc component and thereby 
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Fig- Simplified version of ihe phase-locked loop For analysis, the loop can tie considered a 
combination ot two noninteracting loops: a proportional branch and an integral branch 
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Fig. 2. Contributions to VCO phase changes. Stability factor is the linear pnase change divided 
by the quadratic phase change In the same lime 

tunes the center frequency of the VCO so that it is always equal to the incoming 
data rate- 
In a conventional linear phase-locked loop, the loop error signal is proportional to 
phase error but is used to control the VCO frequency. This introduces an integration 
in the loop transfer function. This integration, in conjunction with the loop filter, 
creates a second-order feedback loop Such loops can exhibit an underdamped 
response to changes in input phase, leading to an undesirable exponential buildup 
of jitter m systems with long cascades of repeaters. 

In the G-link phase-locked loop, the phase-detector dc component is proportional 
to frequency rather than phase. Because the the frequency of the VCO is con- 
trolled by a frequency error signal rather than a phase error signal, no extra in- 
tegration appears m the loop transfer function. This means that no jitter buildup 
results from the action of the integral branch of the loop The jitter statistics are 
simply dominated by the hunting behavior of the high-frequency proportional 
branch of the loop. 

Loop Stability 

To reach a qualitative understanding of the loop behavior, the two branches of the 
loop were assumed to be noninteracting For this assumption to be valid, certain 
conditions must be met 

It is important that the loop be set up so that, between phase samples, the action 
of the proportional branch of the loop dominates over the action of the integral 
branch This can be verified by creating a step change from the phase detector 
and tracking its effect on both halves of the loop Fig 2 shows the contributions to 
the VCO phase change In the proportional path, the VCO is programmed to make 
a small step change in frequency, which causes a linear ramp in the phase error In 
the integral path, the integrator programs a linear ramp in VCO frequency, which 
causes a quadratic walk-off in the VCO phase 

The ratio of these effects at the end of one frame update time gives a figure of 
merit for the loop design The phase change from the proportional branch of the 
loop must be greater than or equal to the phase change from the integral branch 
of the loop ior the system to be stable. In the G-link design, this stability ratio is 
designed to be always greater than 10. 

Richard C Walker 
Principal Project Engineer 
Hewlett-Packard Laboratories 
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Fig. 13. The VCO consists of three variable-delay cells mntigureu' as 
a ring oscillator. 

Each state in tin* state machine has three notations. The lop 
notation is either "FDet" or "Phase." FDel stands for fre- 
quency delect mode, and implies thai ihe frequency detector 
has been enabled in Ihe receiver chip phase-locked loop. 
When the chip is in (his mode, it is important thai no data be 
seni. because the frequency detector is only able lo lock onto 
one of Ihe special training fill frames FFO or FF1. The Phase 
notation means that the receiver phase-lucked loop has 
been switched to phase-detect mode and is ready to allow 
data transmission. The middle notation in each state is the 
fill word that is currently being sent by the node's transmit- 
ter chip. The last notation is Ihe ready-for-dala (RFD) status 
of Ihe transmitter chip. When RFD is low, the transmitter chip 
signals Ihe user to hold off any incoming data while it is 
sending fill frames. When RFD is high, data is sent if avail- 
able, and if not. fill frames are sent 10 maintain link 
synchronization. 

The two bits bracketing the master transition are monitored 
by Ihe receiver chip lo detect a locked condition. If these 
two bits are not complementary for two or more consecu- 
tive frames, it is considered a frame error. The receiver 
chips al both ends of the link are able lo detect dala. con- 
trol) FFO. and FF1 frames and frame errors. Transitions are 
made from each of the states based on the current status 
condition received by the receiver chip. Each of Ihe arcs in 
Fig. 12 is labeled with the stale lhal would cause a transition 
along thai arc. 

If either side of Ihe full-duplex link delects a frame error, il 
notifies the oilier side by sending FFO. When either side re- 
ceives FFO. it. follows the stale machine arcs and reinitiates 
Ihe handshake process. The user is notified of I his anion by 
Ihe deasseiling of RFD. 

This Startup protocol ensures that no user data is sent until 
the link connectivity is fully established. The use of a hand- 
shake training sequence avoids the false luck problem in- 

hereM in phase-locked loop systems thai a tt emp t to lock 

Onto random data with wide-range VCOs. 
Loop Implementation 

The VCO is built from three variable -delay cells configured 
as a ring oscillator I Fig. LI). The ring provides a wide-range 
Inning input and a small "bang-bang" lulling input. The wide- 
rangc input adjusts the delays of each stage from one gale 
delay to three gale delays, thus giving a -i: I V( '( ) frequency 
range. This wide range allows the final system to be specified 

with a 2:1 range over both process and temperature varia- 
tions. The bang-bang Inning input programs a small change 
in the V'O » frequency and is driven by the propoilional 
branch of the loop filter. 



The loop filler is implemented with a charge pump integra- 
tor and a 0.1-uF external capacitor, which is housed within 
the package. The integrator is based on a unity-gain positive 
feedback technique (Fig. 14 ) which cancels out the droop in 
the integrator filter capacitor. The effective dc gain of this 
circuit approaches infinity as the feedback gain approaches 
unity The unity-gain technique achieves high dc gain while 
avoiding rhe stability and noise sensitivity problems of on- 
chip high-gain oj>eralional amplifier designs 

(•-Link Chipset Implementation 

To achieve the best speed and power performance, the 
G-link chips were designed using the IIP B25000 25-GIIz tj 
silicon bipolar process. This process allows mixed-mode 
designs ranging from dense low-power logic structures to 
high-performance analog cells. A three-layer metal system 
allows compact layouts, minimizing chip area and cost. This 
process features transistors with minimum pilch of 2.(> |im. 
Only simple npn transistors and p+ and i>- resistors were 
used in Ihe design. 

Building Block Design 

The G-link chipset is a fully custom circuit using specially 
designed cells as building blocks. These include 1 1 ) logic 
cells consisting of gates, latches, and Hip-flops. (2 ) PLAs for 
low-speed logic-, and (3) I/O cells, which include all of the 
low-speed ECLand high-speed input and output drivers. A 
band-gap reference was also designed to stabilize chip per- 
formance with variations in temperature and power-supply 
voltage. 

Logic Cells and Arrays. Since logic elements are used must 
widely in the G-link chipset, considerable effort wenl into 
optimizing I heir performance, power, and active area. A 
three-level Iree structure was chosen to implement the logic 
functions. All signals are differentia] to improve noise mar- 
gins and to reduce ground currents, which could disrupt the 
analog circuitry. The inputs and outputs of these gales and 
latches are fully level-compatible fur ease of routing. Each 
functional cell has resistor options by w hich the speed can 
be traded Off With power. In all, there are four power classes 
for each logic cell. An example of a master-slave flip-flop with 
a 2:1 input multiplexer is shown to .'Fig; 1 5. This circuit is 
designed to operate up lo 2 Gbits/sat a junction temperature 
of 128*C w ith a fanoul of 10. 
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Low-speed logic is implemented, where possible, wilh array 
structures for compactness and reduced power. The single- 
ended logic PLAs wilh AND-OR planes are designed to he pro- 
grammed using only metal layers. Altogether, two PLA cells 
are used in the transmitter and one in the receiver. 

Input/Output Cells. An effort was made in the I/O design to 
make the chips easy to use. Except Tor the high-speed serial 
signals, all of the chip I/O is 100K ECL-level-compatible. To 
minimize the power dissipation of the chip, ECL outputs are 
limited in driving 10 cm of transmission line with a mini- 
mum characteristic, impedance of 50 ohms terminated into 
300 ohms. For addetl convenience, unconnected inputs are 
internally biased lo low V.Cl, logic levels, and are sensed as 
high levels if the inputs are grounded, 

A special input cell was designed for all gigabit-rate input 
signals. Both differential inputs of the cell are biased to 
ground with 50-ohm terminating resistors. This configura- 
tion allows singled-ended or differential inpul signals to be 
conveniently ac or dc coupled. This cell is used for the 
strobe and high-speed clock inputs of the transmitter and 
for the data and high-speed clock inputs of the receiver. 

The G-link ellipse! is designed to work with cither optical 
fiber or copper coaxial cable media. For cable applications, 
the data input cell of the receiver has an optional equalizer 
lo extend the usable distance of the link. The equalizer cir- 
cuit is designed wilh -'3 (IB of gain peaking ai liOO MHz lo 
compensate for signal roll-offs caused by the skin loss effect 
in coaxial copper cables. Operating at 1.2 fibaud with RG-5S 
coax, the equalizer extends the usable cable length by o\ - er 
50% for a given bit error rate. 

All high-speed outputs are driven by buffered-line-logic 
cells. Buffered-line-logic drivers 4 provide differential out- 
puts capable of delivering 0.7V into 50 ohms, ac or dc coupled 
to ground. If dc is coupled into -1.3V. the levels arc ECL- 
compatible. In addition, the source impedance of the driver 
is matched to 50 ohms wilh a VSWR of less than 2:1. This 



makes the high-speed conneclions of the G-link chips very 
convenient and easy to use. The only requirement is that 
unused outputs be terminated into 50 ohms. 

Band-Gap Reterence. To minimize circuit drills caused by 
environmental changes, a band-gap reference with power 
supply compensation was designed. This circuit provides a 
reference voltage that powers up all cells in both chips. A 
power-down feature in this circuit enables portions of the 
chips to be lurncd off to Conserve power. 

Layouts 

To minimize the design and layout effort, a generic design 
Structure Was used as the basis for all cell layouts. Each of 
the various logic cells was built from the generic array of 
transistors and resistors by customizing the metal intercon- 
nections. The ratio of devices used to total devices available 
reached over 95% in this design. This layout technique has 
the advantage of easy reconfiguration for design revisions. 
The I/O port locations are uniformly defined for all cells to 
Simplify cell interconnection. 

An example of a master-slave flip-flop with a 2:1 multiplexer 
input is show n in Fig. 1(5. This circuit array, measuring just 
104 by 135 pm, is customized with two layers of metal. 

All cells and power buses are designed to be placed using a 
coarse grid. This simplifies the placement of cells in the sys- 
tem design level. Another feature is that all cells have test 
probe points accessible at the top metal such that all con- 
nection signals can be test probed for diagnostic purposes. 

The transmitter and receiver chips each measure 3.5 mm on 
a side. The high-speed and low-speed pads for each chip are 
arranged so that a single package design accommodates 
both chips. 

The design of the chips relied heavily on simulation and veri- 
fication tools such as the Spice simulation program and HP's 
proprietary Bipolar-Chipbtister IC layout system. The Spice 
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Fig. 16; Chip layout of the master-Steve IHp-ftop wiih 2.1 input 
multiplexer. 

eircuil description files wore extracted fedSn the artwork 
including parasitic capacitors for final simulation before 
fabrication. 

Packaging 

A CUStOttl liS-pin ceramic quad Hal package (CQjPP) was 
designed specifically for the G-link chipset il features 
50-ohm transmission lines for Ihe high-speed I/O pins and 
internal o.i-uF capacitors for power supply bypassing and 
for the Integrator of the phase-locked loop. Ii also has inter- 
nal ground vias to minimize inductance, thereby reducing 
noise, lis outline conforms i" standard 68-pin packages. The 
typical chip-lo-case I hernial resistance is under I I ( AY. 
liolh the package and the chips are coinpalil)le with auto- 
matic assembly techniques for high-volume low-cost 
manufacturing. 

After the chips and capacitors are mounted and the pack- 
ages sealed on the lead frame, the units are placed onto 
plastic earners for lead protection. A special test fixture was 
designed to test the final parts in this carrier at full speed. 

Electrical Performance 

The G41nk chips' power dissipations are hoth under 2.5 watts 
worst case. The 2()Vlo-80% rise and Tall limes of Ihe high- 
speed data outputs are under 200 ps. The chipset is specified 
from 1 111 Mbaud to 1.4 Gbaud under all conditions. The 
l« ■« kii| . lime of the phase-locked loop including frequency 
acquisition is less than 2 ms. 



Features and Applications 

The features and flexibility of the G-link chipset make it 
ideal for a wide variety of applications. These applications 
range from computer backplane links a few meters in length 
to wide area networks 10 kilometers long. The low cost and 
ltigh integration level of the G-link chipset make it attractive 
for systems requiring serial transfer rales up to 1.4 Gbaud. It 
can serve as a generic virtual ribbon (.-able or can be used to 
build complete networks and peripheral channels. The G-link 
coding scheme has been accepted by the Scrial-IIlPPI (High- 
Performanee Parallel Interface) Implementors' Group, and 
by SCI-FI (Scalable Coherent Interface-Fiber), an IEEE 
standard. 

This section describes the features that allow the G-link chip- 
set lo be applied to this broad range of applications, it also 
describes a few specific applications, including generic data 
transport, networking standards, and simplex applications. 

Ease of Use 

Since most computing equipment both sends and receives 
data, the great majority of these applications are full-duplex. 
The state machine controller included on the chipset lakes 
care of all the details of starting up such a duplex link. The 
designer needs to be concerned with only two signals: 
ready for data ( RFD ) and data av ailable ( DAV). RFO is the sig- 
nal the slate machine provides to indicate that Ihe link is 
ready for data transmission. DAV is a signal the user controls 
to mark the availability of data. At the receiver, this signal is 
recovered and used lo discern the beginning or end of data 
transmission. 

Some applications generate data in bursts or as packets. 
Such bursty data is handled automatically by the chipset. 
When no data is available to transmit, Ihe user simply deas- 
serls Ihe DAV line at the transmitter. The link will transmit 
FF1 as an idle code to maintain link lock and framing. At the 
receiver, a deassertcd DAV signal indicates I hat data is nol 
being received. At the start of Ihe burst of dala, the user 
asserts the DAV line at the transmitter. The dala is transmitted 
across the link and marked as valid dala al Ihe receiver by 
the receiver's DAV signal. Thus the DAV signals can mark the 
beginning and end of packets while adding no burden lo the 
system design. 

More complicated packet headers can be created using Ihe 
control available (CAV) signal. This signal works like the DAV 
signal, but instead of marking the data as valid data words, it 
marks the dala as special control words. A system designei 
can use these to send packet header information, link or 
System control information, or anything that needs lo be 
treated separately from data. At least 2" control words are 
available, so they can be used to indicate a large number of 
packet addresses or special functions. Few communication 
links have such a rich selection of nondat* words for control 
and signaling. 

Flexibility 

Flexibility was a major goal of Ihe G-link design. To make 
this a high-volume, low-cost part, the chips were designed to 
meet the needs of as many different systems as possible. As 
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descrtbed earlier, the G-link line rode can accommodate 
various word widths. This is very different from block codes 
such as 4B/5B and 8B/10B, which have fixed word widths. 
The (i-link chipset readily accommodates data words of 
width Hi. 17. 20. 21, 33, or 40 bits. The chipset has two fun- 
damental word sizes: lfi or 20 bits. In addition, the flag bit is 
available. Therefore. 17-hit-wide words can be accommo- 
dated by selecting 16-bit frames and using the Hag bit as a 
17th bit. 21-bit words can be transmitted similarly. 32-bit 
words are supported by sending I hem as two Hi-bit frames 
in a row. In this case the Hag bit is used to distinguish the 
first 16-bit frame (e.g.. flag = 0) from the second 10-bit frame 
(e.g., flag = 1 ). It is a simple matter to build the off-chip 
32:10 multiplexers and 10:32 demultiplexers since the flag 
bit automatically keeps track of the necessary frame order- 
ing. 10-bit-wide words are supported analogously. The trans- 
mitter chip accepts either a full-frame-rale clock or a half- 
frame-rale clock for multiplication up to the serial clock rate. 
In other words, for an 800-Mbil/s tlata rale and 16-bit words, 
the chip will accept a 50-MHz frame clock. When 32-bit winds 
are transmitted it acc epts a 25-MHz frame clock. This saves 
the system designer the trouble of doubling the word clock 
outside the chip. 

The G-link chipset supports a wide range of serial transfer 
rales ranging from 1 10 Mbaud all the way up to 1.4 Gbaud. 
This wide range makes it attractive for many types of data. 
Because the chipset requires no off-package I uned elements 
or adjustments, il can lie digitally switched between dala 
rates. This is unlike other systems, which require tuned ele- 
menis and precise adjustments mid operate over very nar- 
row ranges of frequencies. Switching between data rates 
aids testing and debugging. II can also be used to establish 
a standard physical layer that spans several operating 
frequencies. 

Generic Data Transport and Proprietary Channels 

The most prevalent applicalion of the G-link chipset is ge- 
neric data transport hi these applications, the chipset acts 
as a point-to-point unswilched bus extender, or \irtual ribbon 
cable. A great advantage of the G-link chipset is that it auto- 
matically handles startup and framing. Once the link is oper- 
aling, the user can send data continuously, without having to 
insert extra framing characters or form special packets. Other 
links typically require [hat special framing characters be 
periodically inserted into the data stream. For systems trans- 
mitting data continuously for long intervals; periodically 
inserting these special characters can be difficult and ineffi- 
cient. Other link chipsets do not have a built-in hardware 
controller that signals when the link is operating improperly. 
Without these signals the system designer must depend on 
upper-level protocols, resulting in uncertain time delays. 

In many applications, a point-to-point imswitched bus ex- 
lender is sufficient. In these applications, the G-link chipset 



is all that is required and can form a complete communica- 
tion link. The chipset can also be used in more complicated 
networks because it transports any dala formal across the 
link. Examples of standard data formats I hat can benefit 
from a point-to-point bus extender within private networks 
include SONET/SDH, Fiber Channel, and ATM dala. SONET/ 
SDH is a telecommunication standard that specifies data 
rates of 155 Mbits/s, 022 Mbits/s, 1.24 Gbils/s, and higher. 
Fiber Channel is an ANSI standard (X3T9.3) that covers a 
variety of data formats and rales. The IEEE S02.0 standard 
is an example of an ATM (asynchronous I ransfer mode) 
net work. 

The flexibility and ease of use of the G-link chipset enable 
ii to tit a wide variety of applications, lligh-data-rate connec- 
tions to disks and other peripherals are typical uses. These 
applications benefit from the very low overhead, simple 
operation, and high integration of the (i-link chipset. For 
example the IIP 271 1 1A, introduced in 1988, is a fiber optic 
conned ion for disk arrays at 80 Mbits/s. With the tremen- 
dous increase in computing power and I/O rates in the last 
few years, the G-link chipset is well-suited for this type of 
applicalion. 

There is growing interest in using serial links for computer 
backplanes. Computer backplanes are typically jammed with 
hundreds of signals at data rates exceeding 100 Mwords/s. It 
can be difficult to control the skew on parallel data paths at 
high dala rates. In addition, transmitting the data in parallel 
can require significant space. Serial links using optical fiber 
or coaxial cable may lie the only way to transmit data with- 
out degradation by skew. loss, or reflections, while saving 
space. 

Serial-HIPPI 

hi May 1991 the G-link chipset was accepted as the basis of 
the Serial-HIPPI standard. Serial-HIPPI is a specification for 
an SOO-Mbit/s serial data link thai has been agreed upon by 
over 10 vendors and users. Serial-HIPPI transmits data be- 
tween 1IIPPI-P1I nodes, up to 25 meters in coaxial cable, or 
10 km with optical fiber. HIPPI-PH is an ANSI standard 
(X3.1S3-1991) for transmitting digital data in parallel between 
daia processing equipmenl nodes. Il is prcvalenl in super- 
computing and high-end workstation environments. Fig. 17 
showsa diagram of a complete Serial-HIPPI system using 
the G-link chipset. HIPPI-PII data consists or 44-bit-wide 
words at 25 Mwords/s. This data includes 32 dala bits. -1 par- 
ity bits. 7 control bits, and the clock. Ahead of the ( Mink 
transmitter there is an additional circuit called the XMl'X. 
This Circuit reduces the data from 44 bits to 40 bits by re- 
placing two control signals wilh I he chipset's RFD. replacing 
(he HIPPI-PH clock with the clock derived from the incoming 
serial data, and encoding three of the other control signals 
into two lines. The XMl'X then multiplexes the data 40:20. 
This data is transmitted with the G-link chipset as 40-bil 
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words, in the manner described previously. At the receiver, 
the XDEMl X demultiplexes the recovered data from the 
chipset 20:40. then restores the additional four signals. 

Serial-HIPPI is intended to provide compatibility at the serial 
optical and serial electrical interfaces. Therefore, the G-link 
startup sequence and line code are part of the sj deification. 
Hewlett-Pac kard is supplying the (i-link chipset. The MUX 
and XDEMl X arc commercially available. 

SCI-FI 

The (i-link chipset was also chosen as die transport mecha- 
nism for the SCI-FI (Scalable Coherent Interface-Fiber i stan- 
dard (IEEE P1596). SCI is intended to replace traditional 
bac kplane buses, which are limited in physical length and in 
the number Of elements thai can be connected to the bus. 
and arc limited to only one transaction on the bus at a given 
lime. SCI solves these problems using point-to-point com- 
munication between nodes. For Snort distances, dala can be 
sent in parallel on metallic- conductors. For longer distances, 
belter noise performance, and smaller physical size, optical 
fiber or coaxial cable is used to transmit the data serially. 
Data is transmitted as 17-bit words (16 bits plus flag ) at L25 
(ibnud. No additional circuitry is required assuming that ihe 
data is already in the PIS form specified in Ihe standard 
(parallel data, 113 bits plus flag and clock). 

Simplex Applications 

The applications discussed up to now have all been full- 
duplex: there is a forward dala path and there is an equiva- 
lent reverse data path. This covers the great majority of ap- 
plications. However, there are some applications in which a 
particular piece of equipment is primarily B data source or 
sink but not both. 

These applications can be divided into two categories. In the 
first Category are systems where data primarily Hows in one 
direction, but there is a lower-speed method of communicat- 
ing in the reverse direction, An example of this kind of sys- 
tem is a video terminal, which mighl receive a tremendous 
amount of video dala and send back only the very low-rate 
typed commands of a user. Fig. IS shows Ihe (i-link chipset 
G< irtnected for this type of system. A transmitter at Ihe data 
source is connected with a single liber to a receiver at the 
destination. The low-speed return path is used to pass only 
Ihe STATI indication from Ihe slate machine controller at the 
receiver back to Ihe source. This signal makes a transition 
only after power-on. or if lock is lost for some reason. It 
indicates to the transmitter when ihe receiver is locked and 
ready for data, or If the receiver needs (0 be sent FF1 to 
become locked. Since this signal changes state infrcquenlly 
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Fig. 19. In a siniplex system with no return path, such as a video 
distribution system, the receiver input is autumallcallv switrlved (by 
the STMi signal) between the external crystal oscillator for frequency 
lock and the input data for phase lock until the master transition is 
arquinii STROBIN is the transmitter itiila clock input. DOUT is tint' nor- 
mal transmitter serial data output UN is die receiver loopback serial 
dala input DIN is the normal receiver serial data input SIM' is the 
receiver stale machine status out put. fois is the receiver frequency 
detector disable input . L00PEN is titC receiver loopback control. 

and its timing is not critical, it can be sent over any available 
return path, possibly over a single dedicated metallic wire, or 
mixed in with other low-speed data on an RS-232 connection 
or telephone line- 
There are a few communication systems that are strictly 
simplex and have no return path at all. These systems are 
inherently problematic for ensuring data integrity because 
there is no way of knowing the status at the receiving end of 
the link. A typical example of this type of network is video 
distribution. Special techniques should be applied when the 
d link chipset is used for these types of applications. 

A practical and inexpensive solution is shown in Fig. 19. 
Three receiver pins are connected together. This solution 
takes advantage of the (i-link receiver's state machine to 
monitor and switch data paths depending on the loc k condi- 
tions. The only additional component required is mi inexpen- 
sive crystal oscillator operating at the frame rale, which is 
used to frequency lock (he receiver V< '( ). .Viler frequency 
lock. Ihe state machine automatically switches the receiver 
to the data input (LIN) and phase lock lakes place Il'lhe re- 
ceiver does not loc k onto the masiei transition, inlernal 
error checking will cause the State machine to reset and 
switch the receiver back to Ihe crystal reference. The small 
frequency differences between ihe transmit and receive os- 
cillalors will provide a phase shift thai will allow the re- 
ceiver to lock onto the master transition correctly. Typical 
lock limes will be on the order of a few milliseconds, which 
can be improved if necessary by pulling I he crystal refer- 
ence slightly off frequency. Lock limes under 200 ps are 

achievable by adding phase modulation or progra led 

delay in Ihe crystal osc illator path. 
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Summary 

The (i-link chipset is a highly integrated, compact, silicon 
chipset with features that enable it to serve a number of 
application areas. It performs its own stall up and framing. 
This allows a user to Iransmil data continuously, without 
inserting extra characters, in a Virtual ribbon cable mode. 
The chipset includes dala available and control word signals 
which allow the creation of simple packets, The chipset ac- 
cepts a wide range of input word widths, allowing a good 
match to a variety of computer buses. The wide range of 
serial dala rates makes il an ideal transport vehicle for 
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125-Ml.it/s KDDI data to 1.24-Gbil/s SONET data. The chip- 
set can work in simplex systems, allowing its use lor distrib- 
uting video. Two widely accepted networking standards, 
Serial-IIIPPI and SCI-FI, are tailored to the operation of the 
G-link chipset The production volume made possible by this 
broad range of applications should make possible Inily 
low-cost gigabit-rale data links. 
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